评论：关于DC元数据元素的定义格式和各国翻译情况

来自：平台江

平台江 — Mon, 13 Oct 2008 06:22:03 +0000

是的，XML、RDF并不是DC，它仅是一种DC的封装形式。我关心的就是如何找到行业应用认可度高和应用广泛的这种封装形式。

这些封装形式，是否合理到还是其次，最根本也是最重要的应该是大家是否都能支持和认可它。

什么样的包装都无所谓，只要能把内容装进装出即可。

Like or Dislike: 0 0

来自：keven

keven — Mon, 13 Oct 2008 01:10:21 +0000

1、那好，搞学术、理论的与搞技术的大家半斤八两，搞技术的实在也好不到哪去，但至少还对秦始皇心存幻想，这一点比较可爱。
2、DC的“语义与结构/语法分离”是坚持的非常彻底的，这一点XML仅仅是提供了编码的可能，并不是XML与生俱来。你要是说是RDF带来的倒还说得过去。然而这里的RDF也仅仅是指其“三元组”概念而非XML的表达形式，其实RDF还是有不少其它形式的，如N3。
3、DC并非不关心编码，因为这是实践中的一道坎，无法逾越。但是为了不产生误导（历史上已经误导很多了），DCMI现在的主要精力放在完善DC抽象模型上，并通过“新加坡框架”给编码与具体的指导。希望假以时日，并参与进来，推动其成熟。

Like or Dislike: 0 0

来自：平台江

平台江 — Sun, 12 Oct 2008 03:51:02 +0000

在K师关于DC的翻译帖子中又扯到了编码方案，有点扯远了。唠叨了那么多，归纳成如下：
1、支持在各自系统中或拙或巧、或大巧若拙的结构存贮——这种技巧运用的优劣其实仅是体系优劣的指标，跟元数据无关。
2、但系统与系统间的互操作，必须要有统一的交换格式和接口标准。当前我们的应用缺少这个格式与标准。

Like or Dislike: 0 0

来自：keven

keven — Fri, 10 Oct 2008 10:17:26 +0000

DC的先进性在于语义和结构的分离，你可以用任何编码方案来实现信息交换，之所以还对编码争论不休，是因为你们这些搞技术的互不买帐，而Web时代又没有秦始皇。
语义与结构分离适应了网络时代的需要，你想倒退30年，当然也不会有人硬要阻拦你。

Like or Dislike: 0 0

来自：平台江

平台江 — Thu, 09 Oct 2008 14:45:41 +0000

确实，很多人还没弄清楚机读与人读的真谛。DC的元素并不因为其采用了title这类表义的单词就比MARC的200$a高级、更具可读性。实际上，对于计算机来说，title与200$a都仅是一种标识符而已，无所谓谁更具可读性。
所以，很多纠缠在标识符的翻译与对照，纯属多此一举。元数据的标识符，必须具有统一性与唯一性，否则，自说自话，何来交换？机内的唯一的标识符体系，完全可以、也很容易以不同的Label展示出来，但Label跟Name完全是两个东西。
我认为，更深层次的可读性是指元数据的编码方案（所谓数据格式）是否可读，这种可读除了让人可读外，更得让机器可读。因而，采用更具结构化编码方案的元数据，才是比半结构化、非结构化的编码方案的元数据更可读、更先进——从这个层面上说，假如DC、特别是限定性DC没有找到一种更具结构化的编码方案，那么，并不比MARC的ISO 2709编码方案先进。

Like or Dislike: 0 0

来自：雨僧

雨僧 — Tue, 07 Oct 2008 08:14:25 +0000

Ｋ师对Name和Label的解释太精彩了，Ｎａｍｅ和Ｌａｂｅｌ体现了ＤＣ机读和人读两重性。如果Name翻译成不同文字，不是人为造成互操作的障碍，致使ＤＣ的功能丧失。ＤＣ设计的时候，采用了一套基于英语的标识体系，造成一些误解。如果采用MARC的表识体系，可能这样的误解就少了

Like or Dislike: 0 0

来自：beefsteak

beefsteak — Tue, 07 Oct 2008 07:55:12 +0000

还是Label好，一个Label可以表述多个抽象概念，而且SKOS也喜欢Label。

Like or Dislike: 0 0

来自：huizi

huizi — Tue, 07 Oct 2008 00:04:41 +0000

刚看到60秒语录里的话，“我的人生正是：使事业成为喜悦，使喜悦成为事业。—伯特兰·罗素”，这句话用来描述k师，恰当不过。

Like or Dislike: 0 0