| 创作者： | 拉尔夫·莱文 |
| 发布日期： | 1998-02-02 |
| 最新版本： | //www.voudr.com/specifications/dublin-core/dc-z3950/ |
| 发布历史： | //www.voudr.com/specifications/dublin-core/dc-z3950/release_history/ |
| 说明： | 都柏林核心元素集V1.1（DCES）可以用多种语法格式表示。本文档解释了如何用XML对DCE进行编码，提供了验证文档的DTD，并描述了从网页链接文档的方法。 |
本文件与前一稿相比有实质性变化。它包含了反映Z39.50实现者小组（ZIG）一月份会议结果的变更。
本文提出了一种使用都柏林核的机制™ 用于在Z39.50中搜索和检索。关于如何为都柏林核心区的15个基本元素实现这一点的协议™ 已达到版本2的限制范围内。关于如何使用都柏林核心的共识协议™ 带有Z39.50新属性体系结构的限定符和模式等待两个社区的开发完成。本文不是关于Z39.50的教程。要了解本次讨论的细节，至少需要了解Z39.50。
探索哲学
在Z39.50中有三种广泛的搜索理念：极简主义,最大主义和结构主义.
极简主义需要一组语义模糊的接入点，以支持不同实现者之间的广泛互操作性。极简主义者认为，数据库提供者很容易将访问点识别为与“名称”（语义模糊的概念）对应的访问点。对于数据库提供者来说，区分“个人名称”和“公司名称”（语义上更严格的概念）并不总是容易的。此外，客户机实现者及其用户通常不知道或对更具体的访问点不感兴趣。极简主义者愿意放弃一些搜索的准确性，以换取在不同的数据库中找到记录的机会。他们愿意以精确性换取召回。
Maximalism需要大量语义明确的访问点。对于最大化者来说，搜索的特殊性是最重要的。Maximalists愿意放弃与不同数据库的互操作性，这些数据库不支持他们所需的非常特定的访问点，以换取检索到的记录更准确。他们愿意用召回来换取精确性。
极简主义者和极简主义者都在努力实现语义互操作性。他们对记录的结构没有任何断言。
结构主义想要利用结构主义者对被搜索记录的深刻理解。由于具有相同结构记录的数据库相对较少，因此结构主义者比最大主义者进一步降低了互操作性，以换取更高的搜索精度。
这篇论文将提出一种机制，允许所有三个群体按照他们想要的方式进行搜索。此外，本文还将为数据库提供商和客户机开发人员提供建议，以最大限度地提高互操作性，同时提供最大化主义者和结构主义者所要求的特殊性。
都柏林核心元数据集™ 搜索
打造都柏林核心™ 可用于在Z39.50中搜索最初看起来很简单。所需要的只是添加都柏林核心™ 元素使用Z39.50属性集中的属性。围绕这一决定的问题变得很复杂。应该使用哪个属性集？应创建新属性集还是扩展现有属性集？解决方案的重点是哪个实现者社区：版本2还是版本3？
简单的回答是都柏林核心区的15个要素™ 将作为使用属性添加到Z39.50版本2客户端和服务器的Bib-1属性集中，并创建一个新属性集供版本3客户端和服务器使用。新属性集将取决于中描述的功能Z39.50属性体系结构[1] 并将提供在都柏林核心区积极开发的计划和资格认证™ 社区
在版本2中搜索
都柏林核心酒店™ 元素已作为使用属性添加到Bib-1属性集中。
都柏林核心元数据集™ 要素 |
Z39.50使用属性 | |
| 名称 | 价值 | |
| 标题 | DC标题 | 1097 |
| 著者 | DC贡献者 | 1098 |
| 主题 | DC主题 | 1099 |
| 描述 | DC描述 | 1100 |
| 出版商 | DC发行商 | 1101 |
| 日期 | DC日期 | 1102 |
| 资源类型 | DC资源类型 | 1103 |
| 资源标识符 | DC资源标识 | 1104 |
| 语言 | DC语言 | 1105 |
| 其他贡献者 | DC其他贡献者 | 1106 |
| 总体安排 | DC格式 | 1107 |
| 来源 | DC源标识符 | 1108 |
| 关系 | 直流关系 | 1109 |
| 新闻报道 | DC覆盖范围 | 1110 |
| 权限管理 | DC权利管理 | 1111 |
这些新使用属性的语义取自都柏林核心元数据集™ 元数据元素集：引用描述[2].
在版本3中搜索
Bib-1使用属性的拟议扩展提供了对都柏林核心的最小访问™ 用于版本2客户端的元素。但是，为了充分利用都柏林核心区的复杂性™ （即限定符和方案），将提出一个新的属性集。此属性集由Use、Fieldname、ContentAuthority和Structure属性组成。使用属性将是一个枚举列表，最初由15个都柏林核心组成™ 元素。这将支持极简搜索。Fieldname属性将是从中提取的元素名称和元素限定符的列表都柏林核心元数据集™ 限定符/子结构[3]. 这将支持结构主义搜索。字段名组合的合理排列将添加到使用属性的枚举列表中，以支持最大化搜索。此类排列的示例包括创建者个人姓名、标题备选方案和创建日期。提出了新的结构属性。它们可以添加到Bib-1结构属性中，也可以指定为都柏林核心中的新结构属性™ 属性集。其他属性类型（如关系）可从Bib-1属性集或其任何衍生工具中使用。
使用属性
使用属性的主要列表是：标题、作者、主题、描述、发布者、其他参与者、日期、资源类型、格式、资源标识符、源标识符、语言、关系、覆盖范围和权限管理。这些属性的语义在中指定都柏林核心元数据集™ 元数据元素集：引用描述. 都柏林核心™ 使用属性是一个枚举列表，将从1开始连续分配编号。
使用属性的二级列表只是暂时的，需要都柏林核心部门进一步开发™ 社区他们是：
标题备选方案
创建者个人名称、创建者公司名称、创建者地址、创建者个人名称地址、创建者公司名称地址
Publisher PersonalName、Publisher CorporateName、Publisher地址、Publisher PersonalName地址、Publisher CorporateName地址
投稿人个人名称、投稿人公司名称、投稿人地址、投稿人个人名称地址、投稿人公司名称地址
日期创建、日期修改、日期发布、可用日期、有效日期、日期获取、接受日期、日期数据收集
关系创造、关系机械、关系版本、关系包含、关系引用
Coverage PeriodName、Coverage PlaceName、Coverage-t、Coverage-x、Coverage-y、Coverage-z、Coverage Polygon、Coverage Line和Coverage-3d
这些属性的语义在中指定都柏林核心元数据集™ 限定符/子结构. 标题排列的编号从100开始，创作者从200开始，出版商从500开始，投稿人从600开始，日期从700开始，关系从1300开始，覆盖范围从1400开始。
字段名属性
现场名称列表只是暂定的，需要都柏林核心部门进一步开发™ 社区它们是：标题、备选方案、创建者、个人名称、公司名称、地址、主题、描述、发布者、贡献者、日期、创建、修改、发布、可用、有效、获取、接受、数据收集、资源类型、格式、资源标识符、源、语言、关系、覆盖范围、周期名称、地名、T、X、Y、Z、多边形、，直线、三向和右侧管理。这些属性的语义在中指定都柏林核心元数据集™ 限定符/子结构. 这些属性将具有字符串值。
ContentAuthority和结构属性
不幸的是，内容权限和结构的概念在当前的都柏林核心中结合在一起™ 文档这是因为它们只有一个HTML属性可用于标记此数据：Scheme。下面列出的ContentAuthority和Structure属性都列为都柏林核心中的方案™ 文档都柏林核心™ 社区认识到语法歧义，并希望能够澄清这种情况。
ContentAuthority属性
ContentAuthority的名单只是暂时的，需要都柏林核心银行进一步发展™ 社区它们是：LCNAF、LCSH、MeSH、AAT、DDC、LCC、NLM、UDC、MIME、DCPMT、IETF-RFC-1766、Z39.53、ISO-639-1和ISO-639-2B。这些属性的语义在中指定都柏林核心元数据集™ 限定符/子结构. 这些属性将具有字符串值。
结构属性
结构属性列表为：ISO-8601、ANSI-X3.30、IETF-RFC-822、URL、URN、ISBN、ISSN、SICI、FPI。前三个结构属性是日期格式。其他的是标准的标识符格式。FPI是一种正式公共标识符[4]. 这些属性将具有枚举值。实际值将取决于它们是添加到Bib-1还是都柏林堆芯™ 属性集。
客户开发人员指南
Maximist客户端的开发人员应该意识到，他们已经减少了可以搜索的数据库数量，因为他们在搜索中需要语义精确性。如果他们收到错误代码114，这意味着数据库不支持特定的use属性，那么他们应该准备使用语义不那么精确的use属性。代码将附带不支持的Use属性的值。例如，使用Author PersonalName的搜索应该更改为simply Author。客户机开发人员应该知道，某些数据库会自动将过于精确的使用属性转换为不太精确的属性。如果不需要这样做，版本3客户端可以指定语义1和Use属性，这意味着不应该执行替换。
类似的建议也适用于结构主义客户端开发人员，只是尚未指定用于指定不受支持的Fieldname属性的代码。
极简主义客户端开发人员没有类似的回退选项。如果他们发送姓名搜索，而数据库不支持这样的访问点，他们可能会将模糊搜索更改为更具体的访问点，如PersonalName和CorporateName。但是，这并不总是直截了当的。但是，下一节将介绍数据库提供程序如何使此问题变得更容易。
对数据库提供者的指导
Maximist和Structurist数据库的提供者应该意识到，通过极简搜索可以实现最大的互操作性。强烈建议通过将语义上精确的接入点分组为语义上模糊的接入点来提供额外的接入点。例如，Publisher PersonalName和Publisher CorporateName也应作为Publisher提供。
都柏林核心元数据集™ 和记录检索
已开发出检索都柏林核心的解决方案™ 三个Z39.50中的元素记录语法：USMARC、HTML和GRS-1。
都柏林核编码的一种描述™ USMARC记录中的元素由国会图书馆开发，并在都柏林核心/马克/吉尔人行横道[5]. 可以使用USMARC记录语法（对象标识符：1.2.840.10003.5.10）检索这些记录。
都柏林Core的HTML编码™ 元素在中进行了描述一种在HTML中嵌入元数据的建议约定[6] 描述了如何对都柏林核心进行编码™ HTML2.0中的元素。（都柏林核心编码规则）™ HTML 4.0中的元素正在积极开发中，但尚未完成。）Z39.50支持HTML记录语法（对象标识符：1.2.840.10003.5.109.3）。HTML记录也可以封装在GRS-1记录中发送。完成此操作后，HTML将包含在记录中的单个字段中，并使用HTML的变体类型（variant class=2（BodyPartType）、type=1（IANA）、value=text/HTML）对该字段进行标记。
都柏林核心元数据集™ 元素也可以直接在GRS-1记录中检索。在GRS-1记录语法中，元素具有由两个组件组成的数字标记：标记类型和值。有两种公认的标签类型：M和G。都柏林核心™ 已将元素添加到tagset-G中，以嵌入都柏林核心™ 元素在GRS-1记录中，该元素被放入GRS-1记录中的一个字段中，该字段的tagType为2（tagset-G）和中所述列表中的tagValue标记集-G和-M元素[7].
工具书类
[1]Z39.50草稿属性体系结构:http://lcweb.loc.gov/z3950/agency/attrarch/attrarch.html
[2]都柏林核心元数据集™ 元数据元素集：引用描述://www.voudr.com/specifications/dublin-core/dces/
[3]都柏林核心元数据集™ 限定符/子结构:http://www.loc.gov/marc/dcqualif.html
[4] 正式公共标识符：http://www.oasis-open.org/cover/tauber-fpi.html
[5]都柏林核心/马克/吉尔人行横道:http://www.loc.gov/marc/dccross.html
[6]一种在HTML中嵌入元数据的建议约定://www.voudr.com/workshops/dc2/resources-weibel-19960602.shtml[7]标记集-G和-M元素:http://lcweb.loc.gov/z3950/agency/defns/tag-gm.html