元数据设计，实施和最佳实践的创新

以多种语言提出了Dublin Core™的分布式注册表。

创作者： 汤克贝克
发行日期： 1998-10-28
最新版本： //www.voudr.com/specifications/dublin-core/distributed-registry/
发布历史: //www.voudr.com/specifications/dublin-core/distributed-registry/release_history/
描述： 该职位纸张在1998年5月25日在德国波恩的德国国家信息技术研究中心的工作组会议上讨论，并在1998年9月6日在曼谷亚洲理工学院进行了修订，泰国。

注意：这是仅讨论的临时版本;积分6到8尚未获得整体集团的批准。

该职位纸张在1998年5月25日在德国波恩的德国国家信息技术研究中心的工作组会议上讨论，并在1998年9月6日在曼谷亚洲理工学院进行了修订，泰国。

都柏林多语言核心工作组的立场如下:

  1. 国际都柏林核心™社区的参考语言是英语，其所有产出都是用英语讨论和批准的。因此，Dublin Core™的英文版具有特殊状态作为国际流程的规范结果。

  2. 但是，都柏林核心™元素的语义在原则上以任何现代语言同样表达。我们犹豫了提出英语“翻译”以外的语言的Dublin Core™的版本。相反，这些版本可以用作自己的权利作为参考定义，作为以当地特定方式以讨论，适应和扩展的对象。就像任何好的翻译一样，这些版本的方式不需要是单词文字，只要它们以对他们的读者有意义的方式传达规范定义的本质。

  3. 人们目前将“Dublin Core™”与英语标准相关联。我们想调用Dublin Core™的实例化，以各种语言“多语言都柏林核心”或“DC-Multimilual”。有人可能会想到在不同语言中共享的元数据语义，与任何特定语言无关，因此是通用的。

  4. 各种语言中的都柏林核心™元素的版本应该共享一个名称空间。根据1998年10月（DCDM]的Dublin Core™数据模型工作组的决定，命名空间将是：http://purl.org/dc/elements/1.0/“purl.org/dc”部分可能会在未来变化。

  5. 如在RFC用于不合格的Dublin Core™[RFC]中所定义的，Dublin Core™元素由描述性名称（例如，“作者或创建者”）组成，单词标签或“令牌”用于编码方案（例如，“创建者”）和元素定义。描述性名称和元素定义是主要由人类读取，主要由机器令牌。令牌看起来像英语单词，但代表通用元素。通用元素可以具有多种语言的可互换名称和定义。

  6. 法语（DC-French）的Dublin Core™版本http://www.inria.fr.可以具有通用元素 - 规范元素，具有翻译的定义和名称 - 以及特定于DC-French的元素。通用元素将使用Dublin Core™命名空间（此处，http://purl.org/specifications/dublin-core/rec-dces-199809.htm.），虽然本地元素将使用诸如的命名空间http://www.inria.fr/metadata/dublin._core_elements.。

  7. 截至1998年9月，似乎在DC-French的A（假设）RDF架构中的标题元素的定义http://www.inria.fr.看起来像这样：

Le NomDonnéàlaressourceparlecréateurou l'auteur。

  1. 从1998年10月开始，似乎在DC-French的RDF模式中Title元素的定义是这样的:

XMLNS：RDFS =”http://purl.org/dc“>

titre le nomdonnéàlaressourceparlecréateurou l'auteur。

  1. 使用不合格的Dublin Core™和RDF语法的文档的描述将如下所示，独立于该描述的创建者是否提到了DC-English，DC-French或DC-Thai，以及无论该语言如何文档本身（在本案中德语）：

<？XML：命名空间NS =“http://purl.org/metadata/dublin_core_elements”prefix =“dc”？> das erdbeben在辣椒 heinrich von Kleist

  1. 目前尚不清楚机器可读的RDF模式是否应嵌入在人类可读的HTML文档文件中或保持单独。现在，我们应该保持这些单独的，以便在我们知道所需内容时更容易改变它们。

  2. 目前尚不清楚命名空间名称是否应指向RDF架构文件或HTML中的网页。可能元素定义可以从RDF文件动态地提取到HTML文件，反之亦然。此外，XML命名空间的草稿规范[XML]在命名空间名称和可选的URI之间进行区分，指向架构。这显然是进一步研究的问题。无论哪种方式，Namespace名称要随时间都可以改变的点，所以我们可以继续向前写入元数据。

  3. Dublin Core™的其他语言的版本应该引用它们所基于的特定英文版（例如，1.0,1.1,2.0 ...），因为该规范版本将随着时间的推移而发展。例如，Dublin Core™可能会增加超过十五个元素。也许人们可以为每个新版本提供自己的URI。究竟应该如何实现版本控制是一个关于都柏林核心™社区的问题。

  4. 从中央命名空间服务器到其他语言版本的链接应该是机器解释的。用户应该可以传输芬兰语的偏好，并自动进入返回DC-Finnish的URI。截至1998年9月，目前尚不清楚用户是否应该通过中央注册表或直接从赫尔辛基加载他们的Dublin Core™元素名称和定义。

  5. 我们正在开始一段时间的实验，在此期间，我们应该在许多国家邀请Metadata-yoursitutions以各种语言创建Dublin Core™的版本。区域语言或机构差异可能偶尔会导致任何给定语言创建多柏林核心™，但我们认为目前没有理由对此进行限制。最终，我们可能需要一个评估此类版本的过程，同行评审质量和机构在长期维护版本的承诺的一些验证。通过Dublin Core™社区的传递可以是“认证”的版本。

  6. DC-Multimilual应该是共享和协商跨语言的元数据语义的论坛。最初在泰国定义的延期可以纳入通用版本并在全球范围内使用。

过程和可交付成果

  1. 分布式注册表应以多种语言版本以不合格的Dublin Core™开头。在Dublin Core™社区批准合格的Dublin Core™版本之前不应实施子元素。但是，Dublin Core™社区迫切需要在不兼容的子元素损害全局互操作性之前定义这样做的过程。

  2. 随着RDF规范的发展，dc -多语言应该遵循它们。实际上，它可以为RDF提供一个高调的、国际化的、与供应商无关的模型应用程序。反过来，dc -多语言社区应该将其不断发展的需求反馈给RDF工作组，以便在RDF的未来版本中考虑。

  3. DC-Multimilual的分布式登记处将由Dublin Core™的工作组以多种语言，密切咨询，与Dublin Core™咨询委员会，RDF工作组和Dublin Core™社区整体（如此）定期研讨会和DC通用邮件列表）。工作组将维持网页//www.voudr.com/并就DC-International邮件列表进行讨论（http://www.jiscmail.ac.uk/lists/dc-international.html.）

  4. 强烈鼓励当地的实施器开发增强或扩展注册表能力的项目。除了模式之外，这些站点最终最终可以将可下载的模板，元数据编辑器，Java实用程序，用户指南，枚举列表，跨行道持有其他元素集和受控词汇表。

引用的参考文献：
[RDF]http://www.w3.org/tr/1998/wd-rdf-schema-199804049/
[RFC]ftp://ftp.ietf.org/internet-drafts/draft-kunze-dc-03.txt.
[XML]http://www.w3.org/tr/wd-xml-names.
[DCDM]http://www.jiscmail.ac.uk/files/dc-datamodel/decisions.html.