元数据设计、实施和最佳实践方面的创新

都柏林核心区分布式注册计划™ 用多种语言

标题:

都柏林核心区分布式注册计划™ 用多种语言

造物主:
发行日期:
1998-10-28
标识符:
取代:
替换为:
不适用
最新版本:
文档的状态:
这是一个DCMI工作草案
描述文档:

本立场文件源于1998年5月25日在德国波恩德国国家信息技术研究中心举行的工作组会议上的讨论,并于1998年9月6日在泰国曼谷亚洲理工学院举行的会议后修订。

注:此为暂定版本,仅供讨论;第6点至第8点尚未得到整个工作组的批准。


注:此为暂定版本,仅供讨论;第6点至第8点尚未得到整个工作组的批准。

本立场文件源于1998年5月25日在德国波恩德国国家信息技术研究中心举行的工作组会议上的讨论,并于1998年9月6日在泰国曼谷亚洲理工学院举行的会议后修订。

都柏林核心问题工作组™ 在多种语言中,我们采取以下立场:

  1. 国际都柏林核心的参考语言™ 社区是英语的,因为它的所有输出都是用英语讨论和批准的。因此,英文版的都柏林核心™ 作为国际进程的典型结果,具有特殊地位。

  2. 然而,Dublin Core™元素的语义原则上在任何现代语言中都可以很好地表达。我们不愿将都柏林核心™英语以外的语言版本称为“翻译”。相反,这些版本本身可以作为参考定义,作为讨论、调整和以本地特定方式扩展的对象。此外,像任何好的翻译一样,这样的版本不必逐字逐句地直译,只要它们以对读者有意义的方式传达规范定义的精髓。

  3. 人们目前将“都柏林核心™”与英语标准联系在一起。我们希望将不同语言的Dublin Core™实例化的总和称为“Multilingual Dublin Core”或“DC-Multilingual”。人们可能认为DC-Multilingual内部共享的元数据语义在某种意义上独立于任何特定的语言,因此是通用的。

  4. 不同语言中的Dublin Core™元素版本应该共享一个名称空间。根据都柏林Core™数据模型工作组(Dublin Core™Data Model Working Group) 1998年10月[DCDM]的决定,命名空间为:http://purl.org/dc/elements/1.0/“purl.org/dc”部分将来可能会更改。

  5. 如RFC中对不合格都柏林堆芯的定义™ [RFC],都柏林核心™ 元素包括描述性名称(例如,“作者或创建者”)、用于编码方案的单个单词标签或“标记”(例如,“创建者”)以及元素定义。描述性名称和元素定义主要由人类读取,标记主要由机器读取。这些标记看起来像英语单词,但代表通用元素。通用元素可以有多种语言的可互换名称和定义。

  6. 都柏林核心的一个版本™ 法语(DC法语)在http://www.inria.fr可以有通用元素——具有翻译定义和名称的规范元素——以及特定于DC French的元素。环球元素将使用都柏林核心™ 名称空间(此处,http://purl.org/specifications/dublin-core/rec-dces-199809.htm),而局部元素将使用名称空间,例如http://www.inria.fr/metadata/dublin_核心要素.

  7. 截至1998年9月,DC French的(假设的)RDF模式中的Title元素的定义似乎在http://www.inria.fr看起来像这样:

< RDF:描述RDF: HREF = " http://purl.org/metadata/dublin_core_elements #标题" > Le nom donné à la resource par Le créateur ou l'auteur. Le nom donné à la resource par Le Le créateur< / RDFS:评论> < / RDF:描述>

  1. 截至1998年10月,DC French的RDF模式中标题元素的定义似乎如下所示:

xmlns:rdfs="http://purl.org/dc">

Titre Le nom donné à la resource par Le créateur ou l'auteur. txt < / rdfs:评论> < / rdf:描述>

  1. 使用不合格都柏林核心的文档说明™ 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 Finnish的URI作为回报。截至1998年9月,尚不清楚是否应鼓励用户加载都柏林核心™ 元素名称和定义通过中央注册中心或直接从赫尔辛基获得。

  5. 我们正在进行一段试验期,在此期间,我们应该邀请许多国家使用元数据的机构创建都柏林核心版本™ 用各种语言。地区语言或制度差异可能偶尔导致都柏林核心的多个版本™ 但我们认为目前没有理由对此加以限制。最终,我们可能需要一个评估这些版本的过程,对质量进行同行评审,并对机构长期维护版本的承诺进行一些验证。通过认证的版本可以通过都柏林核心认证™ 社区作为一个整体。

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

过程和可交付成果

  1. 分布式注册表应以不合格的Dublin Core版本开始™ 使用多种语言。子元素不应在都柏林核心之前实施™ 社区批准合格都柏林核心版本™. 然而,都柏林核心™ 社区迫切需要定义一个过程来做到这一点,以免不兼容子元素的扩散危及全球互操作性。

  2. DC Multilanguage在发展过程中应符合RDF规范。事实上,它可以为RDF提供一个引人注目的、国际化的、与供应商无关的模型应用程序。反过来,DC多语言社区应将其不断变化的需求反馈给RDF工作组,供RDF未来版本考虑。

  3. DC-Multilingual分布式注册表将由工作组在都柏林核心™实现多种语言与都柏林核心™咨询委员会密切磋商,RDF工作组,都柏林核心™社区作为一个整体(如由周期性车间和dc-general邮件列表)。工作组将维持一个网页,网址为//www.voudr.com/,并就华盛顿特区-国际邮递名单(http://www.jiscmail.ac.uk/lists/dc-international.html)

  4. 强烈鼓励本地实现者开发增强或扩展注册中心功能的项目。除了模式之外,这些站点最终还可以保存可下载的模板、元数据编辑器、Java实用程序、用户指南、枚举列表、到其他元素集的交叉路径和受控词汇表。


引用文献:
[RDF]http://www.w3.org/TR/1998/WD-rdf-schema-19980409/
(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