| 创作者： | 拉尔夫莱南 |
| 发行日期: | 1998-10-09 |
| 最新版本： | //www.voudr.com/specifications/dublin-core/cross-domainaOttribute/ |
| 发布历史: | //www.voudr.com/specifications/dublin-core/cross-domain-attribute/release_history/ |
| 描述： | 搜索几乎总是关于妥协。搜索器所期望的访问点的种类可能在数据库服务器提供的索引中得到准确反映，也可能没有。当搜索器和客户端软件完全了解要搜索的数据库的模式时，搜索是最准确的，搜索者也不会感到惊讶。 |
跨域搜索的问题
搜索几乎总是关于妥协。搜索器所期望的访问点的种类可能在数据库服务器提供的索引中得到准确反映，也可能没有。当搜索器和客户端软件完全了解要搜索的数据库的模式时，搜索是最准确的，搜索者也不会感到惊讶。下一个最不令人惊讶的环境是，搜索器对数据库没有期望，而服务器在单个索引(例如WAIS)中提供完整的文档。这可能不是很准确，但没有人会对结果感到惊讶。任何介于完全理解和完全无知之间的内容都是一种妥协，用户可能会对搜索结果感到惊讶。
在哪个基础上，我们应该使构成跨域属性集的妥协？也许我们使用Bib-1的经验作为跨域属性集可以指导我们的决定。
BIB-1的优势作为跨域属性集
BIB-1的弱点作为跨域属性集
拟议的解决方案
我们需要的是一个属性集，没有太多，但使用属性也不太少。他们的语义应该是足够的，定义它们很清楚，但没有那么紧密地定义它们仅适用于一些主题域。都柏林核心™元素似乎满足这些要求，并具有已被接受的额外益处，因为适用于许多域。最后一点是基于Dublin Core™的属性集，其优于任何其他任意属性列表。
Dublin Core™社区中的讨论/开发点之一是“资格资格”。资格认证允许文档开发人员对Dublin Core™元素的更多信息而不是元素的类型。限定符的示例是方案，可用于限定主题标题的源。此类资格是Z39.50属性集的内在型，并且将在Dublin Core™属性集中定义。
因为资格原产于Z39.50属性集，而不是在Z39.50社区中的辩论主题，我们将单方面解决Dublin Core™问题之一。我们将汇总创建者，贡献者和发布者进入名称的一个抽象属性，并提供语义限定符，以指定这些元素的原始语义意图。
BIB-1属性的清晰优势之一是可用的使用属性数。通过可明智使用语义限定符和内容权限属性，可以在Dublin Core™属性中提供许多这些使用属性的语义。以下实施例如下，但没有尝试制定全面的上市。这项努力等待Z39.50实施者集团批准概念。
当地的可扩展性
Dublin Core™元件是稳定的，描述得很好。它们将从数值的枚举集引用。限定符不稳定，将作为不区分大小写的字符串值引用。将提出一组初始值，但没有理由不能在局部扩展此列表。
DC属性集
抽象属性类型
有十三个抽象的接入点。他们的意思是取自Dublin Core™元素的描述(除了Name，它仅在表中定义)。为澄清起见，添加了斜体字的信息。抽象属性的值和语义是:
| 名称 | 价值 | 意义 |
| 标题 | 1 | 通常由创建者或发布者提供资源的名称。(标题的类型可以用语义限定符属性来澄清。例如前头衔和缩写头衔) |
| 主题 | 2 | 资源的主题。通常，主题将表示为描述资源的主题或内容的关键字或短语。（可以使用内容权限属性阐明主题标题的源。示例包括LCSH和网格。） |
| 名称 | 3. | 与资源相关的人或组织。（可以用语义限定符澄清人或组织的角色的性质。例子是创造者，贡献者和出版商） |
| 描述 | 4. | 资源内容的文本描述，包括在视觉资源的情况下的文档对象或内容描述的情况下的摘要。（可以使用语义限定符属性阐明描述的类型。例子是抽象和注意。） |
| 日期 | 5. | 与资源的创建或可用性相关的日期。这样的日期不与属于覆盖元素的一个属于一个属于覆盖元素，这将与资源相关联，只有智力内容以某种方式关于该日期。(日期的类型可以用Semantic Qualifier属性来澄清。例如:出版日期和收购日期。) |
| 资源类型 | 6. | 资源类别，如主页，小说，诗，工作纸，技术报告，文章，字典。 |
| 格式 | 7. | 资源的数据格式，用于识别可能需要显示或操作资源所需的软件和可能的硬件。 |
| 资源标识符 | 8. | 用于唯一标识资源的字符串或数字。网络资源的例子包括url和urn(实现时)。其他全局惟一的标识符，如国际标准书号(ISBN)或其他正式名称也可以用于此元素。 |
| 源 | 9. | 关于派生当前资源的第二资源的信息。 |
| 语言 | 10. | 资源智力内容的语言。 |
| 关系 | 11. | 第二资源的标识及其与当前资源的关系。（可以用语义限定符阐明关系的类型。） |
| 报道 | 12. | 资源智力内容的空间或时间特征。 |
| 权限管理 | 13. | 一个权利管理说明，一个标识符，它链接到权限管理语句，或链接到提供有关资源的权限管理信息的服务的标识符。 |
字段名称属性类型
Dublin Core™属性集中将提供任何字段名称属性。
查询管理属性类型
在Dublin Core™属性集中不会定义查询管理属性类型(标准化权重、命中数和停止措辞)。它们在Z39.50 Utility属性集中定义。
语言属性类型
不会在Dublin Core™属性集中定义Language属性类型。它在z39.50实用程序属性集中定义。
内容权限属性类型
内容权限属性将包含不敏感的字符串。可以使用查询中的术语指定多个内容权限属性。服务器将与术语的单个抽象属性成对成对的内容权限属性，并确定最佳匹配数据库中的实际接入点的组合。如果在查询中提供了内容权限属性，则必须选择成对组合中的一个，或者服务器必须失败查询。如果客户端愿意让服务器恢复到基本抽象属性的语义，则客户端可以提供z39.50实用程序属性集中定义的null内容权限属性值。目前，内容权限属性仅与主题摘要属性组合使用，但不会排除其与其他抽象属性的使用。
这里提供的内容权限值列表并非全面。预计它将在正式和本地延伸。
| 价值 | 名称 | 源 |
| LCSH. | 国会图书馆主题标题 | 国会图书馆 |
| LC儿童 | 儿童国会主题图书馆 | 国会图书馆 |
| 网 | 医学主题标题 | 美国国家医学图书馆 |
| AAT. | 艺术和建筑学叙述 | Getty信息学院 |
| BDI. | Bibliotek Dokumentasjon Informasjon | 由五个北欧国家（丹麦，芬兰，冰岛，挪威和瑞典）使用和维护的受控主题词汇。 |
| Inspec. | 为物理和工程社区提供信息服务 | 电气工程师机构的信息服务部门。 |
扩展/解释属性类型
不会在Dublin Core™属性集中定义Language属性类型。它在z39.50实用程序属性集中定义。
语义限定符属性类型
语义限定符属性将包括不区分大小写的字符串。可以使用查询中的术语指定多个语义限定符属性。服务器将与术语的单个抽象属性成对的语义限定符属性，并确定最佳匹配数据库中的实际接入点的组合。如果在查询中具有术语的语义限定符属性，则必须选择成对组合中的一个，或者服务器必须失败查询。如果客户端愿意让服务器恢复到基本抽象属性的语义，则客户端可以提供z39.50实用程序属性集中定义的null语义限定符属性值。目前，语义限定符属性仅与名称，描述，日期和关系组合使用，但不会排除其与其他抽象属性的使用。
这里提供的语义限定符列表并非全面。预计它将在正式和本地延伸。
| 价值 | 结合抽象属性 | 意义 |
| 创造者 | 名称 | 主要负责创建资源的智力内容的个人或组织。 |
| 发行商 | 名称 | 负责以现有形式提供资源的实体，如出版社、大学部门或公司实体。 |
| 贡献者 | 名称 | 在Creator元素中没有指定的对资源做出重大智力贡献的个人或组织，但其贡献次于Creator元素中指定的任何个人或组织(例如，编辑、抄写员和插画师)。 |
| 编辑 | 名称 | 准备出版的项目不是他或她自己的项目。 |
| 抽象的 | 描述 | 缩写，准确的资源表示，通常没有添加解释或批评。 |
| 笔记 | 描述 | 一个简洁的陈述，其中可以记录作为扩展物理描述，与其他资源的关系，或内容的信息。 |
| 发布日期 | 日期 | 资源发布的日期。 |
| 购买日期 | 日期 | 获得资源的日期。 |
| 添加日期 | 日期 | 资源添加到数据库的日期和时间。 |
| 日期上次修改 | 日期 | 资源上次修改的日期和时间。 |
| 包含在 | 关系 | 该资源的资源的标识符是零件的。 |
比较属性类型
Dublin Core™属性集中不会定义比较属性类型。它在z39.50实用程序属性集中定义。
格式/结构属性类型
该属性的开发等待Z39.50实施者组和Dublin Core™社区的开发。一个清晰的例子是ISO 1066日期格式。超出了单一的例子，几乎没有一致。
事件属性类型
在Dublin Core™属性集中不会定义发生属性类型。它在z39.50实用程序属性集中定义。
间接属性类型
Dublin Core™属性集中不定义间接属性类型。它在z39.50实用程序属性集中定义。
这个解决方案的问题
对于数据库提供商，它们的数据可能不会整齐地落入一个域。在BIB-1属性集中的许多使用属性中，提供程序可以将几乎所有的接入点映射到BIB-1属性集中的某些内容，并期望客户端将有人想到如何使用该接入点。
下面是这个问题的一个例子。OCLC通过Z39.50访问FirstSearch数据库。这些数据库中的许多都不是严格意义上的书目。其中一些包含有关企业组织的数据;另一些则包含医学期刊的全文。这些数据库中的大多数访问点都可以符合Bib-1 Use属性，即使不是很好。在提议的跨域属性集中，可用的接入点要少得多。数据库提供程序需要在其他特定于域的属性集中查找这些访问点的语义。另外，数据库提供者将开发他们自己特有的、特定于数据库的属性集，这将显著降低互操作性。
新的属性体系结构要求数据库开发人员逻辑上将其数据细分到适当的域，并将其数据映射到这些域中的访问点。客户端开发人员基于对这些访问点的理解做出相同决定的可能性有多大?客户端如何了解搜索特定数据库需要哪些属性集?谁来开发这些领域特定的属性集?客户端和数据库开发人员将如何意识到它们的存在?当我们继续开发新的属性体系结构时，这些问题将会困扰我们。显然，Explain必须在我们的持续发展中发挥重要作用。