Dublin Core™应用概要的指南

创作者：	Karen Coyle 顾问汤姆贝克 DCMI
发行日期:	2009-05-18
最新版本:	//www.voudr.com/specifications/dublin-core/profile-guidelines/
发布历史:	//www.voudr.com/specifications/dublin-core/profile-guidelines/release_history/
描述:	本文档提供了创建都柏林核心应用程序概要文件的指导方针。本文档解释了都柏林核心应用程序概要文件的关键组件，并介绍了开发概要文件的过程。该文档的目标受众是应用程序概要文件的设计者——他们将收集元数据术语，以便在特定的上下文中使用。它不涉及应用程序概要文件的机器可读实现的创建，也不涉及广义上的元数据应用程序的设计。至于更多的技术细节，读者可以参考进一步的资料来源。

1.介绍

在元数据方面，一种大小并不适合所有的元数据。事实上，一个尺码往往不适合很多人。特定社区和应用程序的元数据需求非常多样化。其结果是元数据格式大量增加，甚至跨具有共同元数据需求的应用程序。都柏林核心™ 元数据倡议通过提供设计都柏林核心的框架解决了这一问题™ 应用程序配置文件（DCAP）。DCAP定义满足特定应用程序需求的元数据记录，同时基于全局定义的词汇表和模型提供与其他应用程序的语义互操作性。

注意，DCAP是用于设计不需要使用DCMI [DCMI- mt]定义的元数据术语的元数据记录的通用构造。一个DCAP可以使用任何基于RDF定义的术语，根据需要组合来自多个名称空间的术语。DCAP遵循DCMI抽象模型[DCAM]，这是元数据记录的通用模型。

DCAP包括元数据创建者的指导和元数据开发人员的明确规范。通过明确数据的意图和预期，应用程序概要文件促进了社区内部和社区之间的数据共享和链接。生成的元数据将与链接数据的语义网整合在一起。为了实现这一点，建议由一个团队开发应用程序概要文件，该团队具有所需描述的资源的专门知识、用于描述这些资源的元数据，以及对语义Web和链接的数据环境的理解。

链接数据环境中基于dcap的元数据的互操作性源自其标准基础:

资源描述框架(RDF)，是领域标准赖以存在的基础标准[RDF]。
Dublin Core™抽象模型，元数据记录的通用语法[DCAM]，
Dublin Core™Description Set Profile，应用程序概要文件的约束语言[DCSP]
实现编码的DCMI指南[DCMI- encodings]，

2.Dublin Core™应用程序概要文件框架

DCAP是一个文档（或一组文档），用于指定和描述特定应用程序中使用的元数据。为此，配置文件：

描述一个社区想要用它的应用程序完成什么(功能需求);
描述元数据描述的事物类型及其关系（域模型）；
枚举要使用的元数据术语及其使用规则(描述集概要和使用指南);和
定义用于编码数据的机器语法(语法指南和数据格式)。

新加坡的框架

这些标准如何结合在一起在都柏林核心的新加坡框架中进行了说明™ 应用程序配置文件[DCMI-SF]。底层，RDF提供了建立域标准的基础标准。中间层定义了为应用程序配置提供结构和语义稳定性的域标准。上层包含特定元数据应用程序的设计和文档组件。

以新加坡框架的上层为路线图，接下来的章节将介绍创建DCAP的过程。为了说明这个过程，我们创建了一个描述书籍和作者的简单应用程序概要文件。我们把这个例子叫做MyBookCase．

3.定义的功能需求

任何元数据的目的都是支持某个活动。为活动中使用的应用程序定义明确的目标是必不可少的第一步。

功能需求通过提供目标和边界来指导应用程序概要文件的开发，它是成功应用程序概要文件开发过程的重要组成部分。这种开发通常是一项广泛的社区任务，可能涉及服务管理人员、所使用的材料方面的专家、应用程序开发人员和服务的潜在最终用户。

有帮助创建功能需求的方法，如业务流程建模，以及可视化需求的方法，如统一建模语言[UML]。一些人发现，特定应用程序的用例和场景的定义有助于引出功能需求，否则这些需求可能会被忽略。

功能需求回答以下问题:

您希望通过应用程序实现什么？
你的申请有什么限制?它会什么不试图做什么?
您希望创建的应用程序如何为用户服务?
您的应用程序是否需要执行特定操作，例如排序或下载特定格式的数据？
资源的关键特征是什么，这对数据元素的选择有什么影响?例如，您是否需要处理各种字符集?
你的用户的主要特征是什么?他们是与某一特定机构有关，还是你是为普通大众服务?他们都说同一种语言吗?他们对应用程序将要管理的数据有多专业?他们对所描述的资源类型有多专业?
是否需要考虑现有的社区标准?

功能需求可以包括一般目标以及您需要解决的特定任务。理想情况下，功能需求应该满足元数据创建者、资源用户和应用程序开发人员的需求，以便生成的应用程序完全支持社区的需求。

以下是学术作品应用概要（SWAP）[SWAP]中的一些示例要求：

方便识别开放获取的材料。允许识别研究资助者和项目代码。

一组功能需求可能包括必须支持的用户任务，如书目记录功能需求（FRBR）[FRBR]中的以下内容：

使用这些数据来查找符合用户声明的搜索标准的材料。使用检索到的数据来标识实体。

为MyBookCaseDCAP我们的功能要求是:

使用这些数据检索图书标题搜索。将搜索限制在特定的范围内语言。按顺序对检索到的项目进行排序出版日期. 查找有关给定项目的项目主题．提供作者的的名字和电子邮件地址联系的目的。

4.选择或开发域模型

定义功能需求后，下一步是选择或开发一个域模型的事情元数据将描述这些事物之间的关系。域模型是构建应用程序概要文件的基本蓝图。

应用程序的域模型MyBookCase有两个事情:书和人(书的作者)。我们将在下面看到如何描述书使用诸如标题和语言，并描述人与一个的名字和电子邮件地址．领域模型MyBookCase很简单:

模型可以比这更简单(例如，只是书)或者它们可以更复杂。例如，学术著作都柏林核心™应用程序概要的领域模型是基于图书馆社区的领域模型:书目记录的功能需求(FRBR) [FRBR]。交换定义学术著作取代FRBR更一般的实体工作并引入了FRBR之外的新代理关系，例如isFundedBy和isSupervisedBy．以这种方式，SWAP利用FRBR，但定制FRBR模型以满足其特定需求:

5.选择或定义元数据术语

在为元数据定义了域模型之后，我们需要选择用于描述该模型中事物的属性。例如,一个书可以有一个标题和作者．作者将是人与一个的名字和一个电子邮件地址

然后，下一步是扫描可用的RDF词汇表，以查看所需的属性是否已经声明，是否可以使用。在适当的时候使用现有属性需要更少的工作，并增加元数据的互操作性。如果你需要的属性还没有可用，你可以声明自己的属性，如附录C所述。

对于我们的简单示例，DCMI Metadata Terms [DCMI- mt]是用于基本资源描述的属性来源。资源描述和访问(RDA)标准[RDA_ELEMENTS][RDA_ROLES]正在开发与FRBR直接相关的更广泛的属性集。“朋友的朋友”词汇表具有描述人的有用属性[FOAF]。

在从现有词汇表评估术语时，最明显的考虑是它们的定义。例如，Dublin Core™属性“title”被定义为“给资源的名称”。如果定义符合您的需求，则此属性可以在您的概要文件中使用。然而，在特定应用程序中使用属性的适用性还取决于属性的值类型。用于属性的值类型必须与希望使用的现有属性的允许值类型匹配。

您可能会发现，询问以下有关您打算用于配置文件中所需的每个属性的值的问题很有用。请注意，对于任何给定的属性，可能有多个“是”答案。

要使用自由文本作为属性的值吗?
免费文本是否需要遵循预先定义的格式，如W3C日期格式(“YYYY-MM-DD”)?
是否要从受控列表中选择有效值？
- 如果是，该列表是否已经在某个地方可用，或者需要创建它?
- 您想要将有效值限制在列表中的一个选择中，还是可以使用未列出的值?
- 列表中的值是否被分配了标识符(以uri的形式)?或者您是否预期uri在未来的某一天对他们可用?
单值字符串是否足够(例如，“1989”或“John Adams”)，或者是否有潜在的需要更复杂的描述结构与多个组件，如当一个作者是用一个的名字,电子邮件地址,联系?

再看看我们的MyBookCase，这是我们如何回答有关书:

这个标题将从书中抄写出来。它将是一个自由文本字符串。
我们想用日期属性，例如对检索到的一组书目记录进行排序，因此我们希望确保日期以统一的方式作为结构化字符串表示。
我们想指出语言这样用户就可以限制他们的语言搜索。为了确保语言总是以相同的方式输入，我们需要使用语言的受控列表。
我们想要记录主题从受控列表中。至少有一个可能的受控列表，即国会图书馆主题标题，可供我们使用URI识别词汇值[LCSH]。
我们知道作者不是一个单一的文本字符串，而是用几条信息进行描述，例如的名字和电子邮件地址．

元数据开发过程将使用这些决策来创建附录c中描述的数据元素的技术模型。该分析结果是以下数据模型，它与RDF和DCMI抽象模型一致:

标题为标题我们可以使用都柏林核心™ 属性dcterms:title，可以采用自由文本字符串（“文本”）。

日期因为我们想要执行诸如排序之类的自动化操作日期，我们可以选择Dublin Core™属性dcterms:date。这个属性可以接受一个字符串值。我们可以使用语法编码方案dcterms:W3CDTF来指示值字符串的格式符合W3C日期和时间格式规范。

语言需要从受控列表中选择语言。我们通过要求使用国际标准ISO639-3中列出的三字母代码来表示语言名称(如“eng”表示“English”)，以及作为数据类型的语法编码方案dcterms:ISO639-3来实现这一点。为此，我们可以使用DCMI属性dcterms:language，它既可以容纳语言术语的标识符，也可以容纳字符串。

主题

我们想要记录主题使用受控列表。与创建我们自己的数据相比，利用已经存在的列表更省事，这也增加了数据互操作性的潜力。我们决定国会图书馆主题标题(LCSH)符合我们的需要。因为LCSH中的术语可用RDF词汇表Simple Knowledge Organization System作为正式词汇表[<一个href="//www.voudr.com/www/specifications/dublin-core/profile-guidelines/#SKOS">SKOS]，我们可以通过使用标识主题的URI来指示每个主题。例如，国会图书馆的主题“伊斯兰与科学”被指定为URI<一个href="http://id.loc.gov/authorities/sh85068424">http://id.loc.gov/authorities/sh85068424．DCMI属性dcterms:subject可以支持使用纯字符串或URI。作者因为我们的作者需要用多个组件来描述，例如的名字和电子邮件地址，author属性需要具有非文字范围，以便可以在元数据记录中创建单独但链接的描述。都柏林核心™ 属性dcterms:creator可以与非文字值一起使用，因此我们将在MyBookCase．

属性的选择作者作为一个人遵循相同的模型:

*person*有一个名字，但我们希望将名字和姓氏分开记录，而不是作为单个字符串。DCMI元数据术语没有此类属性，因此我们将从朋友词汇表中获取属性foaf:firstName和foaf:family_name[<一个href="//www.voudr.com/www/specifications/dublin-core/profile-guidelines/#FOAF">FOAF］.

为了将电子邮件地址记录为*person*的联系信息，我们将使用具有非文字范围的属性foaf:mbox，并使用mailto:uri作为值。

下表总结了这些决策，反映了附录c中描述的属性的技术分析。列标题术语在Dublin Core™Abstract模型中定义[<一个href="//www.voudr.com/www/specifications/dublin-core/profile-guidelines/#DCAM">DCAM］.

财产	范围	值字符串	SES URI	值URI	类型的URI	相关的描述
术语：标题	文字	是的	没有	不适用[1]	不适用	不适用
使用dc:创建	文字	是的	是的[2]	不适用	不适用	不适用
使用dc:语言	non-literal	是的	是的[3]	没有	没有	没有
使用dc:主题	non-literal	是的	没有	是的	是的[4]	没有
使用dc:创造者	non-literal	是的	没有	没有	没有	是的
foaf: firstName	文字	是的	没有	不适用	不适用	不适用
foaf: family_name	文字	是的	没有	不适用	不适用	不适用
foaf: mbox	non-literal	没有	没有	是的[5]	没有	没有

[1]这些值不适用于“文字”范围的值。

[2]<一个href="http://purl.org/dc/terms/W3CDTF">http://purl.org/dc/terms/W3CDTF

[3]<一个href="http://purl.org/dc/terms/ISO639-2">http://purl.org/dc/terms/ISO639-2

[4]<一个href="http://purl.org/dc/terms/LCSH">http://purl.org/dc/terms/LCSH

[5] 可以使用mailto:uri提供电子邮件地址。

6.使用描述集概要文件设计元数据记录

下一步是详细描述元数据记录。在DCMI方法中，元数据记录基于描述集模型（本身是DCMI抽象模型的一部分）<一个href="//www.voudr.com/www/specifications/dublin-core/profile-guidelines/#DCAM">DCAM（见<一个href="//www.voudr.com/www/specifications/dublin-core/profile-guidelines/#appb">附录A)，并且记录的设计在使用DSP约束语言的描述集概要(或DSP)中详细说明[<一个href="//www.voudr.com/www/specifications/dublin-core/profile-guidelines/#DSP">DSP］.对于一条记录中的每个描述和语句，DSP定义一个模板,每个模板具有相关性约束指定技术细节，如元素的可重复性或允许值的限制。本节给出一个简单的描述设置配置文件MyBookCase．

一个DSP包含一个描述模板的事情在域模型中，它又包含描述事物的所有属性的语句模板。这些模板还定义了约束使用描述或属性的任何规则，例如值类型或需求和可重复性。

数字信号处理器MyBookCase将有两个描述模板：一个用于书,一个用于人。每个描述模板都有一个用于描述属性的语句模板书或人．语句模板为属性命名，并包含适用于单一类型语句的属性、值字符串、词汇表编码模式等方面的所有约束。

如果我们决定每个元数据记录恰好代表一本书，那么书描述模板将在每个描述集中出现一次，且仅出现一次:

Description: MyBookCase Description template: Book minimum = 1;最大= 1

我们可以决定书必须有一个(而且只有一个)标题，它由属性URI标识<一个href="http://purl.org/dc/terms/title">http://purl.org/dc/terms/title．

语句模板还为用于描述书(根据需要，带有出现选项和其他约束):

Description: MyBookCase Description template: Book minimum = 1;语句模板:title minimum = 1;属性:http://purl.org/dc/terms/title Value类型= "literal"语句模板:dateCreated minimum = 0;最大= 1属性:http://purl.org/dc/terms/created值类型= "literal"语法编码方案URI = http://purl.org/dc/terms/W3CDTF语句模板:语言最小= 0;maximum = 3属性:http://purl.org/dc/terms/language Value类型= "non-literal" takes list = yes语法编码方案URI = http://purl.org/dc/terms/ISO639-2语句模板:subject minimum = 0;属性:http://purl.org/dc/terms/LCSH Value类型= "non-literal" takes list = yes Value Encoding Scheme URI = http://lcsh.info/ Statement template: author minimum = 0;属性:http://purl.org/dc/terms/creator值类型= "non-literal"定义为= person

上面的一些属性的最小出现次数为0(零)。这是一种表示这些属性在我们的记录中是可选的，并且即使这些属性不存在，记录也是有效的方法。有些属性是可重复的，例如语言，最多可发生三次，以及作者，这种情况可能会发生五次。我们将作者定义为具有人，在自己的描述模板中有描述:

描述模板:Person id= Person minimum = 0;语句模板:givenName属性:http://xmlns.com/foaf/0.1/givenname minimum = 0;语句模板:familyName属性:http://xmlns.com/foaf/0.1/family_name minimum = 0;语句模板:email属性:http://xmlns.com/foaf/0.1/mbox minimum = 0;Value类型= "非文字" Value URI = mandatory

给定的人可以有一个可选的名和一个可选的姓，每个都是字面值字符串。一个人也可以有一个电子邮件地址，该地址必须由前缀为mailto:的URI表示。因为我们中的许多人都有不止一个的电子邮件地址，所以我们允许这句话在必要时经常重复。

我们允许人在元数据记录中使用任意次数的描述模板。这似乎与事实相冲突人只能代表一个作者最多五次书描述，但我们预计有其他可能的用途人在我们的记录中，例如一本书的主题，所以我们选择在一般的记录中不限制它的数量。

请注意，每个人Description只包含一个人的数据元素。这也意味着an作者语句将只有一个人价值。如果有两个作者，那就两个作者元数据记录中需要语句，每个语句代表一个人。有人可能允许一个人有多个名字，比如真实姓名和假名;然而，元数据将清楚地区分多作者(多个描述模板)和具有多个名称的单个作者(多个语句模板)。

如果您希望包括一个附属机构作者，您可能希望创建一个机构描述模板，其中包含该机构的名称和位置，然后将链接到作者描述模板。您还可以使用公司名称和位置的其他用途，例如记录有关图书出版商的信息。

这就完成了配置文件的简单描述集MyBookCase；看到<一个href="//www.voudr.com/www/specifications/dublin-core/profile-guidelines/#appb">附录B以XML编码的DSP版本。

7.使用指南

描述集概要文件定义了应用程序概要文件的内容;使用指南提供了“如何”和“为什么”。使用指南为那些将创建元数据记录的人提供了说明。理想情况下，它们解释每个属性并预测创建元数据记录过程中必须做出的决策。元数据创建者的文档显示了DSP中包含的一些相同的信息，但是以一种更易于理解的形式。那些输入的元数据需要知道:这个属性是必需的吗?是重复的吗?我可以使用属性的值是否受到限制?用户界面通常可以回答这些问题，例如，向元数据创建者提供一个有效值列表供其选择。

一些可能出现在使用指南中的规则的例子有:

对于多作者的作品，作者的顺序和要包含的数量(例如:“前三个”或“不超过20个”)
如何解释文档类型的规定词汇
“最小”记录所需的最小元素
字符串中使用的字符集、标点符号和缩写

在一些使用指南相对简单的情况下，可以将其与属性描述一起包含在DSP文档中。Scholarly Works应用程序配置文件是一个示例，其中指导说明与描述集配置文件定义一起包含。

其他社区可能有高度复杂的规则，由于其长度和复杂性，最好以单独的文档形式呈现。例如，一些图书馆作为指南使用的英美编目规则记录在一本600页的书中[<一个href="//www.voudr.com/www/specifications/dublin-core/profile-guidelines/#AACR2">AACR2］.与标题相关的说明出现在它的许多章节，涵盖了许多页的文本。这个长度的指导方针最好从DSP单独提出。

8.语法的指导方针

本文档中描述的技术与语法无关；也就是说，它们不需要任何特定的机器可读编码语法，只要使用的语法能够完全表达DCAP中定义的值和关系。

为了帮助开发人员将他们的应用程序概要文件转换成功能强大的软件应用程序，DCMI开发了各种编码指南[<一个href="//www.voudr.com/www/specifications/dublin-core/profile-guidelines/#DCMI-ENCODINGS">DCMI-ENCODINGS］.描述集概要文件可以使用任何具体的实现语法进行部署，该语法指定了到抽象模型的映射。DCMI已经开发或正在开发在HTML/XHTML、XML和RDF/XML中编码基于dcam的元数据的指南;未来可能还会增加其他项目。只要生成的数据格式与基础标准和DCMI抽象模型兼容，就不限制使用其他类型的语法。

参考文献

AACR2《英美编目规则》，第2版(伦敦:图书馆协会，1978)。

克特姆斯Dublin Core™Collection描述术语。
<<一个href="//www.voudr.com/www/specifications/dublin-core/collection-description/collection-terms/2007-03-09/">//www.voudr.com/specifications/dublin-core/collection-description/collection-terms/2007-03-09/>
另请参见RDF模式<<一个href="//www.voudr.com/www/specifications/dublin-core/collection-description/collection-terms/2007-03-09/cldterms.rdf">//www.voudr.com/specifications/dublin-core/collection-description/collection-terms/2007-03-09/cldterms.rdf>

COOLURISSauermann, Leo, Richard Cyganiak编著。很酷的语义网uri。
<<一个href="http://www.w3.org/TR/cooluris/">http://www.w3.org/TR/cooluris/

DCMI-ENCODINGSDCMI编码指南
<<一个href="//www.voudr.com/www/schemas/">//www.voudr.com/schemas/>

DCMI-MTDCMI元数据术语。2008年1月。
<<一个href="//www.voudr.com/www/specifications/dublin-core/dcmi-terms/">//www.voudr.com/specifications/dublin-core/dcmi-terms/>
另请参见RDF模式<<一个href="//www.voudr.com/www/2008/01/14/dcterms.rdf">//www.voudr.com/2008/01/14/dcterms.rdf>

DCAM

鲍威尔，安迪，迈克尔·尼尔森，安比约恩·纳伊夫，皮特·约翰斯顿和托马斯·贝克。DCMI抽象模型。DCMI推荐标准。2007年6月。
<<一个href="//www.voudr.com/www/specifications/dublin-core/abstract-model/2007-06-04/">//www.voudr.com/specifications/dublin-core/abstract-model/2007-06-04/>

DCMI-SF

尼尔森，迈克尔，托马斯·贝克，皮特·约翰斯顿。都柏林核心应用程序概要文件的新加坡框架。
<<一个href="//www.voudr.com/www/specifications/dublin-core/singapore-framework/2008-01-14/">//www.voudr.com/specifications/dublin-core/singapore-framework/2008-01-14/>

DSP

尼尔森,米凯尔。描述设置概要文件:都柏林核心™应用程序概要文件的约束语言。2008年3月。
<<一个href="//www.voudr.com/www/specifications/dublin-core/dc-dsp/2008-03-31/">//www.voudr.com/specifications/dublin-core/dc-dsp/2008-03-31/>

etermeprint条款。
<<一个href="http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_Terms">http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_Terms>

FOAF

布里克利，丹，利比米勒。FOAF词汇规范0.91。2007年11月
<<一个href="http://xmlns.com/foaf/spec/">http://xmlns.com/foaf/spec/>

FRBR

国际图联书目记录功能需求研究组。(1998)．书目记录的功能要求-最终报告。慕尼黑:kg。阿富汗二月。也可在<<一个href="http://www.ifla.org/VII/s13/frbr/index.htm">http://www.ifla.org/VII/s13/frbr/index.htm>

LCSH

国会图书馆主题标题。在：国会权威和词汇图书馆。
<<一个href="http://id.loc.gov/authorities">http://id.loc.gov/authorities>

联系

关联数据
<<一个href="http://linkeddata.org">http://linkeddata.org>

RDA-ELEMENTS<<一个href="http://metadataregistry.org/schema/show/id/1.html">http://metadataregistry.org/schema/show/id/1.html>

RDA-ELEMENTS<<一个href="http://metadataregistry.org/schema/show/id/4.html">http://metadataregistry.org/schema/show/id/4.html>

RDF万维网联盟。资源描述框架<<一个href="http://www.w3.org/TR/rdf-concepts/">http://www.w3.org/RDF>

RDFS

布里克利，丹和R.V.古哈，编辑。RDF词汇描述语言1.0:RDF模式。W3C推荐标准。2004年2月10日。
<<一个href="http://www.w3.org/TR/rdf-schema/">http://www.w3.org/TR/rdf-schema/>

RDF-引物

马诺拉，弗兰克，埃里克·米勒。RDF底漆。2004年2月10日。
<<一个href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210/">http://www.w3.org/TR/2004/REC-rdf-primer-20040210/>

食谱Berrueta，Diego，Jon Phipps，编辑。发布RDF词汇表的最佳实践配方。
<<一个href="http://www.w3.org/TR/swbp-vocab-pub/">http://www.w3.org/TR/swbp-vocab-pub/>

RFC3066语言识别的标签。2001年1月。
<<一个href="http://www.ietf.org/rfc/rfc3066.txt">http://www.ietf.org/rfc/rfc3066.txt>

交换学术作品申请简介。
<<一个href="http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_Application_Profile">http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_Application_Profile>

UML布奇、格雷迪、詹姆斯·伦堡和伊瓦尔·雅各布森。统一建模语言用户指南。艾迪生·韦斯利，1998年。

附录A:描述集模型(来自DCMI抽象模型)

根据DCMI抽象模型的“描述集模型”[<一个href="//www.voudr.com/www/specifications/dublin-core/profile-guidelines/#DCAM">DCAM]都柏林核心™描述组具有以下结构：

一个描述组是由一个或多个组成的描述
一个描述由…组成
- 0或1描述的资源URI和
- 一个或多个语句
一个声明由…组成
- 正好一个URI属性和
- 正好一个价值的代理
一个价值的代理要么是一个文字值替代或者一个non-literal值替代
- 一个文字值替代由…组成
  - 正好一个值字符串
- 一个non-literal值替代由…组成
  - 0或1价值URI
  - 0或1词汇表编码模式uri
  - 零个或多个值的字符串
一个值字符串要么是一个普通的字符串值或者一个输入值的字符串
- 一个普通的字符串值可能与值字符串的语言
- 一个输入值的字符串与语法编码方案URI
一个非文字值可以被另一个人描述描述．

附录B:MyBookCase描述集配置文件

<？xml version=“1.0”encoding=“UTF-8”>http://purl.org/dc/terms/titlehttp://purl.org/dc/terms/createdhttp://purl.org/dc/terms/W3CDTFhttp://purl.org/dc/terms/languagehttp://purl.org/dc/terms/ISO639-3http://purl.org/dc/terms/LCSHhttp://lcsh.infohttp://purl.org/dc/terms/creatorhttp://xmlns.com/foaf/0.1/givennamehttp://xmlns.com/foaf/0.1/family_namehttp://xmlns.com/foaf/0.1/mbox必填

附录C:在概要文件中使用RDF属性:技术入门

每个应用程序概要设计团队都应该包括理解基于RDF设计元数据的基本原则的成员。本节简要概述了在应用程序概要文件中选择和使用RDF属性所涉及的建模选择。本节通过将技术设计选择与具体的性能要求联系起来，总结如下:

是否使用自由文本，
自由文本是否需要遵循预先定义的格式，
是否应从受控列表中选择有效值，以及
单个字符串是否足够或需要更复杂的值。

RDF属性的基础知识

RDF属性被设计成以一致的方式引用和处理，与它们出现的上下文无关。Dublin Core™元素标题例如，可以在一种语境中用来描述书，在另一种语境中用来描述雕像。当正确使用并与数据的RDF“语法”一致时，这种全局定义的词汇表为将来自各种来源的资源描述集成到一致的数据聚合提供了基础。

为了在基于RDF的元数据中可用，属性必须用统一资源标识符（URI）标识™ 要素标题，使用URI进行标识<一个href="http://purl.org/dc/terms/title">http://purl.org/dc/terms/title（此处缩写为dcterms:title）。良好的实践要求将这些URI声明并记录在某个地方作为“RDF属性”。该声明可以是散文形式，但通常也可以是机器可读的RDF模式，理想情况下由用于URI的Internet域或子域的所有者进行。例如，dcterms:title的URI（通过重定向）解析为RDF模式-<一个href="//www.voudr.com/www/2008/01/14/dcterms.rdf">//www.voudr.com/2008/01/14/dcterms.rdf它以机器可以理解的方式说明dcterms:title是RDF属性。的子域名<一个href="http://purl.org/dc/">http://purl.org/dc/由组织Dublin Core™Metadata Initiative“拥有”(在“控制”的意义上)。

在设计元数据应用程序时，出于许多原因需要使用已经在某处声明的RDF属性。至少，这比声明自己的RDF属性所涉及的额外工作要容易。更重要的是，已知属性的使用为与来自其他来源的元数据的语义互操作性提供了基础。记住，创造词汇表的人可能会换工作或跳槽;研究项目完成他们的工作，最终他们的服务器消失;域名的所有权可能会失效，因此今天解析为RDF模式的uri可能在10年后解析为鞋广告。最好使用由承诺维护它们的组织支持的属性。

RDF属性语义

RDF属性通常与自然语言定义一起提供。应用程序概要文件的设计人员应该注意以与这些定义兼容的方式使用属性。设计人员可以在属性的使用上添加技术约束(比如可重复性)，或者为特定的目的提供更狭窄的定义解释，但是它们不应该与它们的维护者所期望的属性的含义相冲突。

属性的预期含义不仅由自然语言定义决定，还由给定属性与其他属性的正式声明关系决定。定义通常指定一个正式的“域”(可以由属性描述的事物的类别)和一个“范围”(可以是值的事物的类别)。这些附加信息通过支持对RDF属性用于描述的事物进行推断，从而提高了RDF属性的实用性。属性foaf:img (图像),例如,有一个域的foaf:人,一系列的foaf:形象,所以当metadata-consuming应用程序找到元数据使用属性foaf: img,他们可以自动推断与这个属性描述的是一个人,被称为属性的值是一个形象。属性也可以是其他属性的语义细化。例如，属性dcterms:abstract是dcterms:description的子属性，意思是任何被称为具有摘要的东西也可以被称为具有描述。

为了在应用程序配置文件中重复使用属性，特别重要的是检查属性是否打算与文本值一起使用。拟与文本值一起使用的属性（即，根据定义，这些值可能仅由一个值字符串组成，可选地由语言标记（在“纯值字符串”中）或数据类型标识符（在“类型化值字符串”中）扩充）称为具有“文本”范围。具有“literal”范围的属性示例有dcterms:date，它是用rdfs:literal范围声明的，以及foaf:firstName，它被定义为owl:DatatypeProperty。具有“文字”范围的属性的优点是简单。元数据携带元数据，而使用元数据的应用程序只需要一个普通的或类型化的值字符串，从而使元数据易于编码和处理。

除“文字”范围以外的任何属性都被称为具有“非文字”范围。具有“非文字”范围的属性示例范围包括dcterms:license（范围为dcterms:LicenseDocument）和foaf:holdsAccount（范围为foaf:OnlineAccount）。在文字范围属性可能更易于处理的情况下，非文字范围属性更为灵活和可扩展。在描述性元数据中，文字值构成“终端”（从“端点”的意义上讲）；值字符串“Mary Jones”本身不能作为对Mary Jones的任何进一步描述的起点。相反，非文字值具有挂钩，可以附加有关Mary Jones的任何其他信息，例如她的电子邮件地址、机构隶属关系和出生日期。非文字值可能会被重新定义通过以下任意组合呈现：

一个普通的或有类型的值字符串(DCMI抽象模型中的值字符串)，而且不仅仅是一个，而且可能是多个并行的，例如以英语、法语和日语呈现的标题。
标识值资源的URI(值URI)。
标识枚举集(或控制词汇表)的URI，该值是其成员(词汇编码方案URI)。

请注意，文字范围属性和非文字范围属性之间的差异主要是一个建模问题。属性的类型决定了元数据将如何在计算机上以可处理的方式进行编码以供交换，并由使用元数据的应用程序进行解释。最终用户不必看到差异。当在搜索中显示时ult，值字符串看起来是相同的，无论它是直接的文本值还是附加到非文本值的值字符串。

在使用现有属性时，通常由官方定义强制要求在文字范围和非文字范围之间进行选择。如果强制选择还不够(例如，dcterms:date属性有一个文字范围，需要一个更复杂的值)，或者如果在任何地方都找不到一个具有所需语义的属性，那么就必须创造一个新属性(带有新URI)。

创造新的RDF属性

根据定义，都柏林核心™ 应用程序配置文件“使用”已在某个位置定义的属性，即配置文件本身之外的某个位置。如果在任何已知词汇表中都找不到现有属性，那么应用程序概要文件的设计者将需要自己声明一个属性。

声明一个新属性本身并不困难。一个人给它一个名称，给出一个定义，决定它接受的是文字范围还是非文字范围，并为一个名称空间(而不是，例如，under)下的属性创建一个URI<一个href="http://microsoft.com">http://microsoft.com或<一个href="http://amazon.de">http://amazon.de).服务，例如<一个href="http://purl.org">http://purl.org，用于标识DCMI属性，提供可以重定向到更多临时位置的文档的“持久”uri。创建和发布RDF词汇表的指南可以在“用于语义Web的酷uri”中找到[<一个href="//www.voudr.com/www/specifications/dublin-core/profile-guidelines/#COOLURIS">COOLURIS]，RDF引物[<一个href="//www.voudr.com/www/specifications/dublin-core/profile-guidelines/#RDF-PRIMER">RDF-引物和“发布RDF词汇表的最佳实践食谱”[<一个href="//www.voudr.com/www/specifications/dublin-core/profile-guidelines/#RECIPES">食谱]。最佳实践示例包括DCMI元数据术语[<一个href="//www.voudr.com/www/specifications/dublin-core/profile-guidelines/#DCMI-MT">DCMI-MT]， Dublin Core™Collection Description Terms [<一个href="//www.voudr.com/www/specifications/dublin-core/profile-guidelines/#CTERMS">克特姆斯]，以及Eprints术语[<一个href="//www.voudr.com/www/specifications/dublin-core/profile-guidelines/#ETERMS">eterm，这是一个很好的实践，术语也要以RDF模式发布;例如，请参见与DCMI元数据术语相关联的模式[<一个href="//www.voudr.com/www/specifications/dublin-core/profile-guidelines/#DCMI-MT">DCMI-MT]都柏林核心酒店™ 集合描述术语[<一个href="//www.voudr.com/www/specifications/dublin-core/profile-guidelines/#CTERMS">克特姆斯］.

分配文字范围还是非文字范围实质上是简单性和可扩展性之间的选择。仅记录日期(“2008-10-31”)或标题(“乱世佳人”)，值字符串可能就足够了，但对于作者来说，可能需要记录的不仅仅是名字。当有疑问时，明智的做法是指定一个非文字范围。例如，在作者的情况下，非文字范围提供了一个钩子，用于添加电子邮件地址、联系和出生日期，或者使用URI指向作者在自己的应用程序之外的某个地方的描述。因为它们支持使用uri(即，使用uri“作为uri”而不仅仅是“作为字符串”)，非文字值对于实现理想的链接元数据描述至关重要，这些元数据描述使用全局有效标识符进行交叉引用。

将用户定义的数据需求转换为设计决策

现在，我们可以回到向数据内容专家提出的关于每个潜在属性与潜在值的问题。

你想使用免费文本吗?“自由文本”(即字符串)被称为值字符串在DCMI抽象模型中，可以与文字范围或非文字范围的属性一起使用。请注意，在某些情况下，可能需要在单个语句中并行地使用多个值字符串，例如在用多种语言表示值的情况下。这只能与非文字范围属性结合使用。

免费文本是否需要遵循预先定义的格式?如果是，那么值字符串可以和a语法编码方案(数据类型)．

单值字符串是否足够，或者是否需要(或潜在的需要)使用包含多个组件的更复杂的结构?如果值需要超过单个值字符串的任何东西，则使用的属性必须具有非文字范围。如果您偶然发现一个属性具有正确的自然语言定义，但范围错误—例如，具有更有限的文字范围—您可能需要使用带有非文字范围的定义来创建自己的属性和它自己的URI。

您是否希望使用URI来标识该值或指向该值的描述？DCMI抽象模型定义了一个值URI作为一个句法结构值字符串．价值URI不能用于描述文字值;它们必须与具有非文本范围的属性一起使用。当然，可以将URI记录为值字符串-毕竟，URI是一个字符串，但在此基础上使用元数据的应用程序将无法可靠地将该字符串与其他字符串区分开来，以便将其解释为标识符。

是否要从受控列表中选择有效值？如果是这样，则可能出现以下情况：

文本字符串的简单列表可以非正式地记录为描述集配置文件．
简单的文本字符串列表可以更正式地定义为语法编码方案(SES,或数据类型)，使用URI，使列表可引用并可在许多应用程序概要文件中使用。
字符串列表可以解释为概念列表的标签。这就是所谓的词汇编码方案(维斯)．注意，与在SES中列出的单个文本字符串不同，ve的单个概念也可以使用uri标识。
如果值列表已在某处可用，并且已被（如DCMI）确定为语法编码方案或词汇编码方案，然后使用该URI和适当的建模构造。
如果值列表已经在某个地方可用，但是还没有被标识为SES或VES，那么您可能需要解释哪个模型更适合它。有时这两种解释都是站得住脚的。无论您选择哪种方式，重要的是您为编码模式创建的URI必须清楚地声明为其中之一，以避免元数据中的任何歧义。
如果希望将有效值集限制为一个固定列表(而不是允许使用未列出的值)，则可以在描述集配置文件．

一般来说，使用正式定义的值(如受控列表)会增加元数据的精度，从而提高其对自动处理的适用性。适当地使用SES和VES是朝着这个方向迈出的重要一步。然而，使用RDF词汇表简单知识组织系统(Simple Knowledge Organization System)，越来越多地将uri分配给受控词汇表中的单个术语[<一个href="//www.voudr.com/www/specifications/dublin-core/profile-guidelines/#SKOS">SKOS]。例如，国会图书馆主题标题中的“万维网”概念最近被指定为URI<一个href="http://id.loc.gov/authorities/sh95000541">http://id.loc.gov/authorities/sh95000541#concept。随着受控词汇表变得越来越“透明化”，使用这些词汇表在开放网络上查找和集成对来自多个来源的资源的访问将变得更加容易。VES结构可以灵活地适应从值字符串独自一人,值字符串与类型的uri，然后从那里到价值URI（有或没有类型的uri)．