| 创造者: | 皮特·约翰斯顿 |
| 发行日期: | 2005-12-07 |
| 最新版本: | //www.voudr.com/specifications/dublin-core/dc-elem-refine/ |
| 发布历史: | //www.voudr.com/specifications/dublin-core/dc-elem-refine/release_history/ |
| 描述: | 本文档描述了Dublin Core元数据中使用的“元素细化”概念。它试图解释一个属性“精炼”另一个属性的结果。目的是澄清，在某些情况下，作出这样的主张可能是适当和有用的，而在其他情况下，这样的主张可能导致矛盾。 |
都柏林核心元数据集™ 元素和元素细化是属性。属性是“用于描述资源的特定方面、特征、属性或关系”。根据DCMI抽象模型，所有这些“方面、特征、属性和关系”都涉及资源之间的关系[DCMIAM]。每个属性对应于一种关系类型，例如，资源“由”代理“创建”(代理是第二个资源)，或者资源“与”某个概念“有关”(这个概念也是一个资源)。
属性本身就是一个资源，一个“概念性的”资源。当DCMI将属性添加到它的“DCMI Namespaces”之一时，它会创建该概念的可读描述，并以URI的形式为属性分配一个全局唯一标识符。
URI的作用域是全局的：URI的使用就好像它表示相同的概念、相同的关系类型，无论它在哪里被引用。此外，中描述的持久性策略都柏林核心的名称空间策略保证DCMI分配给其属性的uri总是表示相同的基本概念[DCMINS]。因此，URI的赋值意味着其他方可以使用这个唯一标识符，它的全局唯一性和持久性的组合意味着引用是明确的。
分配给属性的URI可以在Dublin Core™元数据描述中的语句中使用。根据DCMI抽象模型， DC元数据描述是关于单个资源的一个或多个语句的集合，而语句是由对属性的引用和对第二个资源的引用组成的两部分构造[DCMIAM]。
对描述主题的引用是通过两种方式之一进行的。描述可以使用URI显式引用主题资源(“资源URI”)。另外，描述的主题可能是隐式的，这取决于描述发生的格式和/或上下文:例如，对于嵌入在XHTML文档[DCHTML]中的DC元数据描述，该XHTML文档就是描述的主题。为简单起见，本文档中提供的示例反映了提供资源URI的情况。
对属性的引用也采用URI的形式(“属性URI”)。对值的引用可以采用URI或“值表示”的形式。出于本文讨论的目的，这些示例展示了引用采用URI(“值URI”)形式或字符串形式表示(“值字符串”)形式的最简单情况。
每个语句都断言在两个资源之间存在由属性指示的类型关系:作为描述主题的资源和值(参见[1]):
| 资源URI | 语句 | ||||
|---|---|---|---|---|---|
例:book1 |
|
除了为它声明的每个属性提供定义和标识符之外，DCMI还描述了这些属性之间的关系。如果两个属性的定义是这样的:当两个资源由第一个属性关联时，它们也由第二个属性关联，则第一个属性被称为“精炼”，或者是第二个属性的“精炼”。
例如，属性的定义使用dc:创建是“资源创建日期”，属性的定义是dc:日期是“资源生命周期中与事件关联的日期”。资源的创建日期总是“资源生命周期中与事件关联的日期”，因此使用dc:创建房地产优化了市场dc:日期财产。
DCMI发布的可机器处理的模式包括所有DC元素和元素细化的描述。在元素细化的描述中，使用属性URI包含一条语句rdfs: subPropertyOf来自RDF词汇表描述语言（RDF模式）[RDFS]。这表示两个属性之间存在关系，该关系的性质由RDFS概念定义rdfs: subPropertyOf：
属性rdfs:subpertyof是rdf:property的一个实例，用于声明由一个属性相关的所有资源也由另一个[rdfs]相关。
这rdfs: subPropertyOf断言使读者或软件应用程序在遇到使用“细化”或子属性生成的语句时能够推断出新的信息(请参阅[2])。
所以如果断言
使用dc:创建rdfs: subPropertyOf dc:日期
并使用使用dc:创建作为属性URI，例如。
| 资源URI | 语句 | ||||
|---|---|---|---|---|---|
例:book1 |
|
那么我们就可以推断出
| 资源URI | 语句 | ||||
|---|---|---|---|---|---|
例:book1 |
|
这个结果适用于全部的语句使用元素细化的URI作为属性URI:每当两个资源通过元素细化关联时，它们也会通过相应的元素关联。一个元素精炼另一个元素的断言rdfs: subPropertyOf属性之间存在关系-只有当属性的定义支持该结论时才应该建立关系。
如果只有一种情况推断语句不为真，那么不应该断言精炼/subPropertyOf关系。
例如，考虑属性的情况marcrel:自己的(“目前拥有一件物品或收藏品的个人或组织”)和dc:贡献者（“负责对资源内容作出贡献的实体”）。这两个属性都描述了将资源与“实体”（能够执行某些操作的代理）关联的关系类型。(修订)marcrel:自己的属性是美国国会图书馆基于MARC Relator Codes [MARCREL]定义的属性集的一部分。)
对于一个特定的资源，一个实体既是该资源的所有者又是该资源的贡献者，这很可能是真的，但这不适用于全部的用例。也就是说，在某些资源中，作为资源所有者的实体并没有对资源的内容做出贡献:并不是所有的资源所有者都是资源贡献者。如果marcrel:自己的被描述为dc:贡献者，那就意味着每一个语句使用marcrel:自己的属性URI将导致语句使用dc:贡献者作为属性URI，这是不可取的。
还请注意没有对于子属性断言，绝对不会限制元数据作者说:对于任何给定的资源，则同一实体既是所有者又是参与者。元数据作者只是将这两条语句分开：
| 资源URI | 语句 | ||||||
|---|---|---|---|---|---|---|---|
例:book1 |
|
作为第二个例子，考虑一下dc:日期，定义为“资源生命周期中与事件关联的日期”。如果实现者使用属性外部：更新频率表示“资源修改的周期性”，并将该属性描述为细化元素dc:日期，则下列语句可能被推断出来:
| 资源URI | 语句 | ||||
|---|---|---|---|---|---|
例：文件1 |
|
资源，这些资源是语句使用的适当值外部：更新频率对于使用dc:日期，就是这样不适当地将该属性描述为元素的细化dc:日期．
同样,考虑dc:权利，定义为“关于资源中所拥有的和对该资源拥有的权利的信息”。假设一个实现者使用一个属性外部：privacyIndicator指示文档是否应该公开可用，并指定应该使用布尔值(yes/no)。如果该属性被描述为元素的细化dc:权利，这将导致推断出以下陈述：
| 资源URI | 语句 | ||||
|---|---|---|---|---|---|
例：文件1 |
|
可能有一种观点认为严格来说，布尔值与dc:权利，但很难将“Yes”的价值视为“关于对该资源持有的和对该资源拥有的权利的信息”。所以，再一次，它是不适当的描述外部：privacyIndicator作为元素的细化dc:权利，因为这些语句可以被推断出来。
在DCMI所做的声明中，任何给定的属性都只是其中一个的主体rdfs: subPropertyOf关系:一个DC元素细化仅仅细化了一个元素——尽管一个元素可以被多个元素细化。
但是，原则上，可能会做出多个断言，结果是在语句中使用属性时多个可以推断出存在其他关系。
所以如果断言
exterms: bookDistributor rdfs: subPropertyOf exterms:经销商
而且
exterms:bookDistributor rdfs:dc:publisher的子权限
并使用图书发行商作为属性URI，例如。
| 资源URI | 语句 | ||||
|---|---|---|---|---|---|
例:book1 |
|
然后下面的两个这些说法也是正确的:
| 资源URI | 语句 | ||||||
|---|---|---|---|---|---|---|---|
例:book1 |
|
注意它是不选择一个选项而不是另一个的问题，或者两个行为不同的应用程序:二者都声明隐含在全部的只要这两个应用程序“了解”两个子属性关系，它们就应该生成相同的推论。
断言…存在的能力rdfs: subPropertyOf涉及来自DCMI命名空间的属性的关系不限于DCMI。
另一个词汇表的发布者可能希望声明该词汇表中的属性是来自DCMI命名空间的属性的子属性（甚至来自DCMI命名空间的属性是来自其词汇表的属性的子属性）。
国会图书馆基于MARC Relator代码[MARCREL]定义了一组属性，可用于断言资源和代理之间的关系。在适当的情况下，声明这些属性与来自DCMI命名空间的属性之间的子属性关系非常有用。例如
marcrel: ARR rdfs: subPropertyOf dc:贡献者
（marcrel:加勒比海盗表示连接音乐作品及其编曲者的属性。)
有了这些信息，都柏林核心™ 遇到的应用程序
| 资源URI | 语句 | ||||
|---|---|---|---|---|---|
例:music1 |
|
可以推导出这个命题
| 资源URI | 语句 | ||||
|---|---|---|---|---|---|
例:music1 |
|
这意味着没有“先验知识”的应用程序marcrel:加勒比海盗，但它确实从的断言中推导出适当的推论rdfs: subPropertyOf关系，可以利用dc:贡献者陈述这样的过程增强了元数据应用程序之间的互操作性。
子属性断言可以由非所涉及属性的所有者/发布者的第三方提出。假设设计人员在不知道存在Dublin Core™的情况下构造了一个元数据词汇表。在描述他们的属性时，他们没有提到他们的属性这个概念exterms:作曲家与dc:创建者. 如果实现者同时使用该元数据词汇表和DCMI词汇表，那么他们可以使用Subperty断言：
exterms:词曲作者rdfs:dc:创建者的子角色
这样，当他们的Dublin Core™应用程序遇到
| 资源URI | 语句 | ||||
|---|---|---|---|---|---|
例:music1 |
|
该应用程序可以派生该语句
| 资源URI | 语句 | ||||
|---|---|---|---|---|---|
例:music1 |
|
最后，应该再次强调，在DC元数据中使用来自其他元数据词汇表的属性时，不需要存在与DC属性的子属性关系。在MARC Relator属性的情况下，在许多情况下可能存在子属性关系，但对于那些不存在这种关系的属性，例如owner属性marcrel:自己的，仍然可以部署在DC元数据描述中的语句中。
［1］为了简洁起见，在示例中，uri由限定名表示。假设前缀与命名空间名称关联如下:
http://purl.org/dc/elements/1.1/http://purl.org/dc/terms/http://purl.org/dc/dcmitype/http://www.loc.gov/loc.terms/relators/http://www.w3.org/1999/02/22-rdf-syntax-ns#http://www.w3.org/2000/01/rdf-schema#http://example.org/terms/http://example.org/things/［2］本文件不涉及细节如何应用程序获取关于子属性关系存在性的信息。这些信息可以由应用程序的开发人员内置到应用程序中，也可以从某些外部数据源获取。该来源可能是其中一个属性的所有者/出版商提供的数据，也可能是第三方提供的数据。诸如元数据注册中心之类的服务可以作为许多不同机构提供的属性信息的来源，并且确实可以使用聚合的数据来提供基于对多个子属性关系的推断的功能。
(DCMIAM)
DCMI抽象模型
//www.voudr.com/specifications/dublin-core/abstract-model/
(DCMINS)
Dublin Core™元数据计划(DCMI)的命名空间策略
//www.voudr.com/specifications/dublin-core/dcmi-namespace/
(DCHTML)
用HTML/XHTML元和链接元素表示Dublin Core™
//www.voudr.com/specifications/dublin-core/dcq-html/
(MARCREL)
代码列表:第一部分:相关代码
http://www.loc.gov/marc/relators/relators.html
[RDFS]
RDF词汇表描述语言1.0（RDF模式）
http://www.w3.org/TR/rdf-schema/