关于DC元数据元素的定义格式和各国翻译情况
由于申报DCMES元数据国标的需要，在这里汇总一些有关DC元数据元素定义和各国翻译情况的资料。
由于早期（DCMES1.1-1999更新成2003版以前）DCMI对于元数据元素的定义是遵循ISO11179标准“数据元素的基本属性（Basic Attributes of Data Elements）”，从中选取了10个属性进行定义（参见这里）：
- Name – The label assigned to the data element
- Identifier – The unique identifier assigned to the data element
- Version – The version of the data element
- Registration Authority – The entity authorised to register the data element
- Language – The language in which the data element is specified
- Definition – A statement that clearly represents the concept and esential nature of the data element
- Obligation – Indicates if the data element is required to always or sometimes be present (contain a value)
- Datatype – Indicates the type of data that can be represented in the value of the data element
- Maximum Occurrence – Indicates any limit to the repeatability of the data element
- Comment – A remark concerning the application of the data element
从中可以看出Name属性是赋予元素的一个给人识别的标签，而Identifier是给机器读的。
后来（DCMES1.1-2003开始）感到这种定义会在整个元素集的定义中产生大量冗余信息，而且ISO11179作为一个庞大的元数据应用标准体系，只用了这么一点点也不尽合适，于是从实际出发，采用了W3C和IETF的标准，即把给人读的名字定义为标签（Lable）属性，并明确把URI作为Identifier，Name就作为一个机读的token。这样就发展成目前对于DC元素的定义形式（参见 这里）：
| Name: | A token assigned to the term, unique within the term’s DCMI namespace. |
| Label: | The human-readable label assigned to the term. |
| URI: | The Uniform Resource Identifier used to uniquely identify a term. |
| Definition: | A statement that represents the concept and essential nature of the term. |
| Type of Term: | The type of term as described in the DCMI Abstract Model |
进一步地，如果必要，还会有以下属性：
| Comment: | Additional information about the term or its application. |
| See: | Authoritative documentation related to the term. |
| References: | A resource referenced in the Definition or Comment. |
| Refines: | A Property of which the described term is a Sub-Property. |
| Broader Than: | A Class of which the described term is a Super-Class. |
| Narrower Than: | A Class of which the described term is a Sub-Class. |
| Has Domain: | A Class of which a resource described by the term is an Instance. |
| Has Range: | A Class of which a value described by the term is an Instance. |
| Member Of: | An enumerated set of resources (Vocabulary Encoding Scheme) of which the term is a Member. |
| Instance Of: | A Class of which the described term is an instance. |
| Version: | A specific historical description of a term. |
当然在目前的DCMES（俗称简单DC）的元素集定义里，没有Type of Term（因为都是Element，不存在子元素或修饰词），但有Comment和References（说明了取值方式）。
DC元数据在发展演进过程中逐渐被许多国际组织和国家认可，成为国际标准或者国家标准。目前有：
- ISO15836-2003
- NISO3985-2007（取代NISO3985:2001）
- CEN CWA 13874
- IETF RFC 5013 （取代IETF RFC 2413）
- 英国国家标准
- 澳大利亚国家标准
- 芬兰国家标准
- 丹麦国家标准
- 荷兰国家标准
其中除了NISO3985-2007根据DCMES最新版更新的之外，其余大都基于1999年的DCMES1.1版的文本（其中ISO15836的修订比原计划有所拖延，几个国家标准都没有查到文本，这里列出的是各国的翻译）：
- Catalan – maintained by the Biblioteca de Catalunya
- Chinese (Big 5 font) — hosted by Cheng-Juei Wu, Prof. in Library & Information Science Dept. at Fu-Jen University (undated)
- Czech
- Danish – by Leif Andresen, Danish National Library Authority
- Dutch
- Greek (Word file) — by Sarantos Kapidakis, Laboratory on Digital Library and Electronic Publishing Ionian University (2003-11-20)
- Japanese – by Shigeo Sugimoto
- Arabic — maintained by Hachim Haddouti (1998-12-29)
- Chinese (Simplified) — maintained by Shanghai Library (2003-06-02)
- Finnish (PDF) — maintained by the National Library of Finland (2002-10-09)
- French — by Anne-Marie Vercoustre, Inria (2002-03-26)
- German (PDF) — by KIM (Kompetenzzentrum Interoperable Metadaten) (2007-08-22)
- Italian — by Central Institute for the Union Catalogue of Italian Libraries and for Bibliographic Information (undated)
- Interlingua — by Emerson José Silveira da Costa (2001-02-01)
- Korean — by Sam-Gyun Oh, SungKyunKwan University (1999-07-02)
- Latvian (PDF) — translation by the National Library of Latvia (2006-12-18)
- Maori — Te Kete Ipurangi — The Online Learning Centre (undated)
- Marathi — by Shubhada Nagarkar, Bioinformatics Centre, University of Pune (undated)
- Norwegian — by Frank B. Haugen and Carol van Nuys, Nasjonalbiblioteket (2002-03-04)
- Persian — by Sayyed Mahdi Taheri (2007-06-05)
- Polish — by Marek Nahotko, EBIB Electronic Information Bulletin For Librarians (2000-10-28)
- Portuguese — by José Luis Borbinha, National Library of Portugal (2002-07-29)
- Russian — by Alexey Beshenov (2007-06-06)
- Swedish — by Stina Degerstedt, The Royal Library, National Library of Sweden (2006-01-30)
- Thai (Word file) — by Praditta Siripan, Technical Information Access Center (TIAC) (1999-07-02)
其中可以看出，如果是采用ISO11179格式定义的早期文本，有一些的确把Name翻译成本国语言了，有一些两种语言都保留（包括我们的翻译），有些则没有翻译（如韩文），而Identifier一定是保留英文。后来的翻译，则一律跟随DCMI的改变而改变。
DCMI目前的态度很明确，元素的Name是一个机读的token，并且为了能够作为一个合法URI的组件，不能有任何特殊符号（例如空格、冒号等），以此来看，如果规定两个Name（中英文）似乎更有些荒谬了，试想这样的话注册系统如何来做？术语服务是按照哪个作为URI？
相对而言Label则自由得多，可以是多个单词，也可以是任何语种、符号，在具体应用中也可以有其它别名（这当然不属于本文档所规定的范围）。
人的认识总有一个过程，但是一旦跨过了某各阶段，再折回去走老路就显得十分没有必要了。当然，如果充分发表意见之后，大多数人仍然认为应该按照老的做法走，也是没有办法的事情，毕竟事情是向前推进了，有标准总比没有好。
Popularity: 75% [?]
huizi Said on 十月 7th, 2008 at 8:04 上午 quote
刚看到60秒语录里的话，“我的人生正是：使事业成为喜悦，使喜悦成为事业。—伯特兰·罗素”，这句话用来描述k师，恰当不过。
Like or Dislike:
0 
0
[回复]
beefsteak Said on 十月 7th, 2008 at 3:55 下午 quote
还是Label好，一个Label可以表述多个抽象概念，而且SKOS也喜欢Label。
Like or Dislike:
0 
0
[回复]
雨僧 Said on 十月 7th, 2008 at 4:14 下午 quote
Ｋ师对Name和Label的解释太精彩了，Ｎａｍｅ和Ｌａｂｅｌ体现了ＤＣ机读和人读两重性。如果Name翻译成不同文字，不是人为造成互操作的障碍，致使ＤＣ的功能丧失。ＤＣ设计的时候，采用了一套基于英语的标识体系，造成一些误解。如果采用MARC的表识体系，可能这样的误解就少了
Like or Dislike:
0 
0
[回复]
平台江 Said on 十月 9th, 2008 at 10:45 下午 quote
确实，很多人还没弄清楚机读与人读的真谛。DC的元素并不因为其采用了title这类表义的单词就比MARC的200$a高级、更具可读性。实际上，对于计算机来说，title与200$a都仅是一种标识符而已，无所谓谁更具可读性。
所以，很多纠缠在标识符的翻译与对照，纯属多此一举。元数据的标识符，必须具有统一性与唯一性，否则，自说自话，何来交换？机内的唯一的标识符体系，完全可以、也很容易以不同的Label展示出来，但Label跟Name完全是两个东西。
我认为，更深层次的可读性是指元数据的编码方案（所谓数据格式）是否可读，这种可读除了让人可读外，更得让机器可读。因而，采用更具结构化编码方案的元数据，才是比半结构化、非结构化的编码方案的元数据更可读、更先进——从这个层面上说，假如DC、特别是限定性DC没有找到一种更具结构化的编码方案，那么，并不比MARC的ISO 2709编码方案先进。
Like or Dislike:
0 
0
[回复]
keven Said on 十月 10th, 2008 at 6:17 下午 quote
DC的先进性在于语义和结构的分离，你可以用任何编码方案来实现信息交换，之所以还对编码争论不休，是因为你们这些搞技术的互不买帐，而Web时代又没有秦始皇。
语义与结构分离适应了网络时代的需要，你想倒退30年，当然也不会有人硬要阻拦你。
Like or Dislike:
0 
0
[回复]
平台江 Said on 十月 12th, 2008 at 11:51 上午 quote
在K师关于DC的翻译帖子中又扯到了编码方案，有点扯远了。唠叨了那么多，归纳成如下：
1、支持在各自系统中或拙或巧、或大巧若拙的结构存贮——这种技巧运用的优劣其实仅是体系优劣的指标，跟元数据无关。
2、但系统与系统间的互操作，必须要有统一的交换格式和接口标准。当前我们的应用缺少这个格式与标准。
Like or Dislike:
0 
0
[回复]
keven Said on 十月 13th, 2008 at 9:10 上午 quote
1、那好，搞学术、理论的与搞技术的大家半斤八两，搞技术的实在也好不到哪去，但至少还对秦始皇心存幻想，这一点比较可爱。
2、DC的“语义与结构/语法分离”是坚持的非常彻底的，这一点XML仅仅是提供了编码的可能，并不是XML与生俱来。你要是说是RDF带来的倒还说得过去。然而这里的RDF也仅仅是指其“三元组”概念而非XML的表达形式，其实RDF还是有不少其它形式的，如N3。
3、DC并非不关心编码，因为这是实践中的一道坎，无法逾越。但是为了不产生误导（历史上已经误导很多了），DCMI现在的主要精力放在完善DC抽象模型上，并通过“新加坡框架”给编码与具体的指导。希望假以时日，并参与进来，推动其成熟。
Like or Dislike:
0 
0
[回复]
平台江 Said on 十月 13th, 2008 at 2:22 下午 quote
是的，XML、RDF并不是DC，它仅是一种DC的封装形式。我关心的就是如何找到行业应用认可度高和应用广泛的这种封装形式。
这些封装形式，是否合理到还是其次，最根本也是最重要的应该是大家是否都能支持和认可它。
什么样的包装都无所谓，只要能把内容装进装出即可。
Like or Dislike:
0 
0
[回复]