都柏林核心
都柏林核心
关于DCMI 主题 成员 董事会 使用板 理事会
推特 YouTube GitHub RSS提要

DCMI本地化和国际化社区

会议报告:多语文都柏林核心™工作组

地点:
德国国家信息技术研究中心(GMD)，德国波恩
会议日期:
1998-05-25
召集人:
托马斯·贝克((电子邮件保护)),椅子/报告员
版本:
1998-06-28(最终修订版)
出席者:
托马斯·贝克((电子邮件保护)),椅子/报告员
Jose Borbinha ((电子邮件保护)）
Diann Rusch-Feja ((电子邮件保护)）
雷金纳德·费伯((电子邮件保护)）
萨兰托斯·卡皮达基斯((电子邮件保护)）
乌尔里希·泰尔((电子邮件保护)）
安妮-玛丽·维尔库斯特((电子邮件保护)）

背景

多语言都柏林核心™工作组起源于1997年3月堪培拉研讨会上的一个分组会议，会上我们一致认为，除英语以外的其他语言版本的都柏林核心™应该共享一组全球有效的、机器可读的令牌。[DC4]非正式后续讨论分别在赫尔辛基的都柏林核心™研讨会(1997年10月)、日本筑波的数字图书馆国际研讨会(1997年11月)、华盛顿特区的欧盟-国家科学基金会元数据工作组(1998年2月)和筑波的第十一届数字图书馆研讨会(1998年3月)上举行。Tom Baker在日本的两次会议上以多种语言发表了与Dublin Core™相关的论文。(ISDL97)

在3月的研讨会上，Eric Miller (RDF工作组的负责人)、Shigeo Sugimoto和Tom Baker详细讨论了如何使用新兴的资源描述框架以多种语言创建Dublin Core™的分布式注册表，从几种语言的Simple Dublin Core™版本(15个不确定元素)开始。RDF模式工作组于1998年4月9日发布的工作草案[RDF]包括了简单都柏林核心™的英语模式，但保留了与多语言的都柏林核心™模式相关的关键问题。随后进行了电子邮件交流，其中RDF工作组的成员，特别是Charles Wicksteed，帮助定义了为了推进这一工作而需要做出的技术决策。这些技术问题是波恩会议讨论的重点。

波恩会议的与会者商定如下:

  1. 国际都柏林核心™社区的参考语言是英语，因为它的所有产出都是用英语讨论和批准的。因此，作为国际进程的规范结果，都柏林核心™的英文版具有特殊地位。
  2. 但是，Dublin Core™元素的语义原则上在任何现代语言中都可以很好地表达。我们不愿将都柏林核心™的英语以外语言版本称为“翻译”。相反，这些版本可以作为它们自己的参考定义，作为讨论的对象，以当地特定的方式进行改编和扩展。此外，像任何好的翻译一样，这样的版本不需要逐字逐句，只要它们以对读者有意义的方式传达规范定义的本质。
  3. 人们目前将“都柏林核心™”与英语标准联系在一起。我们希望将各种语言的都柏林核心™实例化的总和称为“多语种都柏林核心”或“dc -多语种”。有人可能会认为DC-Multilingual中共享的元数据语义在某种意义上独立于任何特定的语言，因此是通用的。
  4. 不同语言的Dublin Core™元素版本应该共享一个名称空间。截至1998年5月，名称空间名称的一个可能候选名称是“http://purl.org/metadata/dublin_core_elements”。这需要整个都柏林核心社区进行讨论和批准。
  5. 按照简单都柏林核心™(Simple Dublin Core™，RFC)的RFC定义，都柏林核心™元素由描述性名称(例如，“Author or Creator”)、用于编码方案的单字标签或“令牌”(例如，“Creator”)和元素定义组成。描述性名称和元素定义主要由人类读取，而标记主要由机器读取。这些符号看起来像英语单词，但代表通用元素。通用元素可以在多种语言中具有可互换的名称和定义。
  6. 都柏林核心™的法语版本(dc -法语)在http://www.inria.fr可以有通用元素——具有翻译定义和名称的规范元素——以及特定于DC-French的元素。通用元素将使用Dublin Core™名称空间(在这里，http://purl.org/metadata/dublin_core_elements)，而局部元素将使用诸如http://www.inria.fr/metadata/dublin_core_elements。在DC-French的RDF模式中http://www.inria.fr，那么，Title元素的定义如下所示:

Le nom donne a la resource par Le createur ou 'auteur.

  1. Dublin Core™元素具有人类可读的描述性名称、机器可读的标签(令牌)和人类可读的定义。然而，到1998年5月为止，资源描述框架模式核心只支持后两种——令牌和定义。对于用英语描述Dublin Core™，这不会造成大问题，因为令牌几乎与名称相同(例如，“Creator”与“Author or Creator”)。然而，为了用其他语言表达模式，我们还需要支持人类可读的描述性名称。如果RDF规范在Schema Core中不支持这一点，也许Dublin Core™社区应该定义自己对RDF的扩展(用RDF术语来说是一种新的“属性类型”)，可以在官方的Dublin Core™名称空间中维护它。
  2. 使用Simple Dublin Core™和RDF语法的文档描述将如下所示，不管该描述的创建者引用的是DC-English、DC-French还是DC-Thai，也不管文档本身使用的是哪种语言(在本例中是德语):

<？xml:namespace ns="http://purl.org/metadata/dublin_core_elements" prefix="DC"?Das Erdbeben in ChiliHeinrich von Kleist

  1. 机器可读的RDF模式是应该嵌入到人类可读的HTML文档文件中，还是应该保持独立，目前还不清楚。现在我们将把它们分开，这样当我们知道需要什么时，我们可以更容易地改变它们。
  2. 不清楚名称空间名称(参见上面的第4条)应该指向RDF模式文件还是指向HTML中的Web页面。也许元素定义可以动态地从RDF文件提取到HTML文件，反之亦然。此外，XML名称空间规范草案[XML]区分了名称空间名称和指向模式的可选URI。这显然是一个有待进一步研究的问题。无论哪种方式，名称空间所指向的内容都可能随着时间的推移而改变，因此我们可以放心地继续编写元数据。
  3. 其他语言的Dublin Core™版本应该引用它们所基于的特定英文版本(例如，1.0、1.1、2.0…)，因为该规范版本将随着时间的推移而演变。例如，Dublin Core™可以增加到超过15个元素。也许可以为每个新版本提供自己的URI。究竟应该如何实现版本控制是整个Dublin Core™社区的一个问题。
  4. 从中央名称空间服务器到其他语言版本的链接应该是机器可解析的。用户应该可以传输芬兰语的首选项，获得dc - finland的URI，然后从赫尔辛基加载Dublin Core™元素名称和定义。
  5. 我们正着手进行一段试验，在此期间，我们应该邀请许多国家使用元数据的机构以各种语言创建都柏林核心™的版本。区域语言或制度差异可能偶尔会导致以任何给定语言创建多个版本的都柏林核心™，但我们认为目前没有理由对此加以限制。最终，我们可能需要一个评估这些版本的过程，对质量进行同行评审，并对一个机构长期维护一个版本的承诺进行一些验证。通过的版本可以被都柏林核心™社区作为一个整体“认证”。
  6. DC-Multilingual应该是一个跨语言共享和协商元数据语义的论坛。最初在泰国定义的扩展可以纳入通用版本并在全球范围内使用。

过程和可交付成果

  1. 分布式注册表应该从多种语言的Simple Dublin Core™版本开始。在Dublin Core™社区批准Complex Dublin Core™版本之前，不应实施子元素。
  2. 随着RDF规范的发展，DC-Multilingual应该遵守这些规范。实际上，它可以为RDF提供一个高调、国际化和厂商中立的模型应用程序。反过来，dc -多语言社区应该将其不断发展的需求反馈给RDF工作组，以便在RDF的未来版本中加以考虑。
  3. DC-Multilingual的分布式注册将由多语言都柏林核心™工作组在与都柏林核心™咨询委员会、RDF工作组和整个都柏林核心™社区(由定期研讨会和meta2邮件列表代表)密切协商后实施。工作组将在//www.voudr.com/并在邮件列表中进行讨论http://www.jiscmail.ac.uk/lists/dc-international.html．
  4. 强烈鼓励本地实现者开发增强或扩展注册中心功能的项目。除了模式之外，这些站点最终还可以保存可下载的模板、元数据编辑器、Java实用程序、用户指南、枚举列表、到其他元素集的交叉路径以及受控词汇表。

参考文献引用