DC元素的中文翻译
最近参加了汪东波老师主持、业界许多知名单位派代表参加的“DC元数据元素集国标项目”,顺便把我们经营了多年的“DC中文网”(改版前在这里)更新一下。最主要的工作是对DCMES (Dublin Core Metadata Element Set,即DC的非限定版)的ISO和NISO版本,以及几个中文翻译版进行比较,记了一些笔记。发布在这里,以期引起更多人的讨论和批评指正,并供大家参考引用。
以下修订笔记,记录于2007年10月21日,作为备忘,并供讨论参考。
1、建立了各元素单独的参考编辑页面以便逐个进行讨论修订。同时也建立了一个15个元素的汇总页面。
2、外链的标准规范文档需要在本地做镜像,以备网络或其他问题引起查考不便。
3、《都柏林核心元数据元素集(1.1版)》最新的中文翻译文档与原文档(2006年12月18日)在元素的说明体例上并不完全一致,因为当时中文版网站缺乏版本管理(没有用Wiki)而保留了部分原有的体例(例如“术语类型”、“状态”和“发布日期”等)。
4、ISO和NISO标准和中科院基本元数据项目对于元素的排列都是按照重要性(title, creator…),而DCMI是按照字顺(contributor, coverage…),我们也将参照ISO、NISO的顺序对元素进行排列,而不是以字顺排列。
5、目前DCMI定义元素时,名称(Element Name)作为元素的标识(id),是给机器读的。而标签(Label)是给人读的。因此前者都用小写,后者首字母用大写。目前修订过的ANSI/NISO Z39.85:2007和IETF RFC 5013都是这样,而中科院项目是把名称也翻译成了汉语,标签保留首字母可以大写。ISO 15836:2003还是名称和标签首字母都大写。
6、目前的文本在元素的定义和内容上尽可能与经过审核的最新的ANSI/NISO Z39.85:2007、IETF RFC 5013和Dublin Core Metadata Element Set, Version 1.1保持一致(经过核对,这三者是完全一致的)。DCMI中文网的文字上有与上述文档不一致的地方。
7、DCMES在修订过程中(如NISO Z39.85:2007),对于注释进行了简化,特别去除了具体的实例(例如identifier去掉了URI、DOI、ISBN举例)。考虑到GB需要添加实例,某些简化掉的内容可以添加到实例中。
8、由于目前在文本方面尽可能参考/采用新版的DCMES,有一些地方与ISO 15836:2003不尽一致,是否合适,需要项目组集体讨论。本人建议,因为ISO 15836:2003也即将面临Review,我们还是以尽可能反映最新的标准讨论成果为宜。
Popularity: 99% [?]
Tags: DC, DC Metadata, Metadata, 中文翻译, 元数据, 元数据, 标准规范, 笔记, 都柏林核心元数据
















平台江 Said on 十一月 12th, 2007 at 12:30 上午 quote
知道“DC元数据元素集国标项目”的启动,有喜有忧。
喜得是,有了某种官方的规范,如同漆黑的行路中看到一盏明灯。
忧得是,假如这盏明灯把人引入歧途……
规范的制定,从总体来看,有总比没有好。但如果在制定时随意和盲从,就可能随数据量的增加,导致积重难返。
今天给您发了一邮件,请查收。
Like or Dislike:
0
0
[回复]
keven Said on 十一月 12th, 2007 at 9:03 上午 quote
所言极是,好在目前所想确立的国标只是DC元数据的最基本的15个元素语义。
Like or Dislike:
0
0
[回复]
远洋 Said on 十一月 13th, 2007 at 1:03 上午 quote
上述建议中第5条是正确的,这样才能跟dc namespace上的具体内容联系起来,也是DC元素在全世界不管什么语种和使用条件下保证语义一致性的必要条件。
请注意DCMI目前网上的1.1版本还有具体内容未更改.例如
RFC 3066 (Language Tags) 已被 RFC 4646取代。又如关于‘subject’:
Current version (2006-12-18) on the DCMI website: “Typically, the *topic* will be represented …”
Z39.85-2007: “Typically, the *subject* will be … ”
所以应该以NISO2007通过的版本来定。一般来说国际标准5年就失效,必须重新投票,看是保留,修订,还是撤换。ISO2003版估计明年就会更新,也许跟以前一样,直接拿NISO版去通过。
Like or Dislike:
0
0
[回复]
图谋 Said on 十一月 14th, 2007 at 11:33 上午 quote
谢谢分享!谢谢诸位老师的讨论!
Like or Dislike:
0
0
[回复]
西北图客 Said on 十一月 14th, 2007 at 10:57 下午 quote
K师:您好
最近我在浏览《全国数字图书馆标准与规范》网站上的技术报告,感觉这个标准确实做的比较规范与细致,涉及数图建设的方方面面面的标准,但问题在于这样庞大的标准体系将来的能否为国内数图建设的各个单位所采用,毕竟我们的数图建设已有时日,已经形成了多种事实上的建设方案与标准,而这样的建设而难另起炉灶按新的标准去做,所以我认为标准与规范应是简易可行,过于复杂的体系反而不利于数图的建设,好像这个标准体系的复杂性仍有加重的趋势。
Like or Dislike:
0
0
[回复]
keven Said on 十一月 18th, 2007 at 10:45 上午 quote
图客你好!Leon从西安带来了你的问候,非常感谢!也感谢你的留言,谈几点不成熟的看法,供参考。
1、标准规范的复杂性并不是问题,因为与网络相关的复杂性是可以封装在工具或应用中的,并不需要人人掌握。
2、目前科技部标准规范项目的成果在我看来并没有完成,现在培训可以起到普及知识的目的,但是距离直接应用,还有距离。
3、就目前元数据的标准规范(说大一点:网络信息组织的标准规范)来看,我们需要建立或修订各类词表(对于各类领域应用)、建立编码规范(上述两者相加就是应用纲要)、研讨应用模型和抽象模型,并在此基础上详细制定各相关领域的应用规则和著录规则,再行开发工具软件和应用开发环境,以及建立行业标准规范的评测、考核、认证制度,整个架构才能建立起来。
4、目前DCES建立国标,也算一个实质的起步,虽然简单,但象征意义不容忽视。
5、上述3比较理想化,但大致框架是这样的,这样的框架即使不能有意识地建立,也会逐渐无意识地产生。喜欢走弯路是一种中国特色,即使我们有袁主任张主任,恐怕也冇办法。
Like or Dislike:
0
0
[回复]
远洋 Said on 十一月 18th, 2007 at 10:48 下午 quote
支持Keven的几条,另外想将之细化,解释。
我们可以把元数据标准分为几种, 分别侧重于:
1。Data Structure — 那些元数据元素集合(element set, or metadata schemes),如DCMES,定义元素的语义和关系。
2。Data Values — 各类词表、词汇(value encoding schemes)。
3。Data Content — 这类标准侧重于具体的应用,例如用于图书馆的编目条例AACR,用于档案工作的DACS, 用于文化物件的CCO (Cataloging of Cultural Objects). 它们虽然也规定一些最基本的元素,但是是从应用角度来说的,一般不成为元素集 (也有拉出来另立门户的)。
4。Data Exchange –如MARC 2709, MARCXML, 还有其它的元素集的表现格式,例如LOM有3种不同的编码格式。
元素集可以用不同表现格式,生成不同的metadata schemas. 这些schemas可以直接用XML工具读,自动产生编元数据记录用的templates, 由此产生的数据便可以直接交换了。
(请注意schemes 和 schemas 的不同)。
这些标准都可以在一个元数据标准文件中得到集中反应,例如DC要规定什么元素下应该用什么encoding scheme. 用另一句话说,哪个字段要依据哪种词表。
应用纲要(Application Profile) 偏重于Data content。在集中了所需要的元素后(可能从不同元数据集选来),做出很具体的指导性的编目建议。应用纲要可以针对一个元数据表(例如DC-Lib), 或者一种文献(例如学位论文),或者一个专业数据库或项目(例如医学、教育)。应用纲要也可以用编码语言做成schemas。
我认为现在中国更应该发展应用纲要,以求得与国际产品的互操作和分享。应用纲要本身也可以被通过作为行业或国家标准。
有一个很重要的中国还没有形成的服务是元数据的注册系统(metadata registry), 用于注册上述所有标准的整体,也可以对其部分注册(比如元素),以便于匹配,供产生应用纲要的项目来选取合适的元素。
Like or Dislike:
0
0
[回复]