来自：平台江

平台江 — Wed, 24 Sep 2008 05:50:14 +0000

好久没来K师博客中作客了，今天google别的资料时，无意中在返回结果中发现K师话题中提到贱名，顺着链接打开此帖，看后不禁心有戚戚。
如果要想了解数字图书馆时代的新潮概念，我看K师的博客如果自谦第二，没有人敢称第一。除了因K师深厚的英文功底能看明白相关文档并有专职的研究时间外，更因其有不吝发表独立见解的学术无私风范，故而在其博客中才没有人云亦云照本宣科的无趣。
奈何我等俗人，为了商业利益自顾不暇，都有好几个月没来此洗耳恭听了。
不在其位，无法谋其政的无奈更增加了我们想多多听取在其位者的声音，然感觉到了太多的高深莫测和不置可否，我等凡夫俗子在惶恐中不知所措。是故，令人生出DC元数据在图书馆应用有如communism是如此美好、如此让人企盼的感慨。
专家精英宁有种乎？都是从不知到知，唯有不自闭、不唯上、不盲从、不守旧，方能充实并完善自己的知识体系。想来“DC-Lib应用纲要”当初也是由小众、个别精英提出来的，正因其小众，任是精英，可能也有挂一漏万的疏忽。如果心有惴惴，却怕人耻笑自己无知而不敢表达困惑甚至置疑，企盼着有人振臂一呼以便附和，这不应该是专家精英或在其位者应有的态度。
完全赞同K师用1:1原则来反对“DC图书馆应用纲要”中对“格式（Format）”的修饰词“媒体(medium)”的说明。事实上，任何应用采用DC，并不是局限于采用其有限的元素标识与限定词，而是可以充分在其体系原则框架下进行扩展，反过来，只要不符合其体系原则的，就不能说是DC应用，挂着羊头卖狗肉的事我们不干。
产生这些理解歧义的原因，我看还是由于当前没有推出一个合理的限定性DC编码方案，过于抽象的概念不如形式化的东西直观明晰——这个形式化的东西就是元数据的编码方案（所谓数据格式）。
“dcterms:medium只能用于描述资源的物理形态（格式），这在抽象模型的domain-range中说得很清楚了。因此dcterms:IMT不能用于修饰dcterms:medium，只能修饰dc:format或dcterms:format”——Andy的这个解释也非常正确。我始终认为，编码体系限定与语义修饰限定都是修饰DC元素的东西，编码体系限定与语义修饰限定间没有任何关系。或者这样表达：编码体系限定是限定元素或限定被语义修饰词限定后的元素。
那么，要想形式化表达清楚这种关系，可以这样来：

可以视之为隐含或忽略了编码体系限定的编码方案，它与下面显式声明了编码体系限定的编码方案是等价的、结构一致的：

假如忽略语义限定词，采用IMT编码方案限定，合法的描述应该是这样的：
application/pdf
之所以说它是合法的描述，是因为声明采用dcterms:IMT编码体系限定，那么描述值就应该是采用这个体系中的合法值“application/pdf”。它等价于显式声明语义限定词后的编码方案：
application/pdf
有趣的事情来了：
假如这样来表达：
aabbcc
从数据规范来讲，描述信息是错误的。aabbcc是啥玩意儿？因为在dcterms:IMT编码体系中，没有这玩意儿的定义！但从元数据编码方案来看，形式上是没有错，语义上也没有错，都表达出了“资源的Internat媒体类型是某某某”的概念——至于aabbcc是什么媒体类型，那是另一回事了。这也是一种挂羊头卖狗肉的作法：我声明我采用dcterms:IMT规范词汇来描述资源的载体格式，你们就要当我是采用这个编码体系。至于是否允许我随意录入描述词汇或先占个位，以后再改正，这就是数据制作过程中，通过系统或规章制度来控制与防范的事了。
所以，“DC图书馆应用纲要”中对“格式（Format）”的修饰词“媒体(medium)”的说明中，除了违背了1:1原则外，所谓：“格式”如果不带修饰词，则应该采用IMT的编码体系修饰词作为取值，特指资源的电子形式”更应该是一种错误。照此说法，不带限定词的简单DC，除了采用IMT的编码体系修饰词取值外，就无法描述资源了？
难道只能有隐含IMT限定的是合法的：
application/pdf
或显式IMT限定的是合法的：
application/pdf
就不能有采用其它编码体系限定或根本不采用编码体系限定的描述？以下编码方案难道是错的？
牛皮纸
这似乎有违DC的Dumb Down原则——顺带求教一下，Dumb Down该翻译为“向上兼容”还是“向下兼容”？这个翻译结果有点相对论的味道，嘿嘿。
其实，“牛皮纸”与“aabbcc”，从客观语义（借用这个词汇不知是否能准确表达我的意思）来说，应该是等价的，都是采用某个字符对资源的格式进行的某种描述。至于这两个不同的描述值的主观语义，在特定的环境中，它们可以相同、也可以不同——有点扯远了。
由于多见这样的编码方案：

把元素语义限定等同于元素一样表现为XML的元素，但又不得不把dcterms:medium和dcterms:extent与dc:format捆绑在一起宣传——不捆绑起来，如何体现口口声声中的元素及其语义限定的DC概念呢？
这个时候，才有什么“格式”如果不带修饰词，则应该采用IMT的编码体系修饰词作为取值的解释了，本来不是问题的问题，这么一解释，反而让人更糊涂了。

来自：keven

keven — Fri, 05 Sep 2008 01:00:53 +0000

DCMI的Application Profile是特指DC元数据在特定领域应用的规范方案，DC-Lib就是指DCMI的图书馆应用工作组在很多年前就开始讨论和研发的一个AP(应用纲要)，即文中有链接的那个。这两年这个项目似乎停顿下来，倒是后提出的一个“资源集合”的AP先行推出了，目前已经是DCMI的推荐规范了。
老鲍的意思是说当初这个工作组理解错了，他自己曾经做过这个组的主席，因此他说他也有责任，但是这个错误不是他的任期内产生的，他只是没有纠正而已。
现在DCAM成为DC所有应用的纲领和原则，所以凡是与此相违背的，都是要被抛弃的，呵呵。
感谢留言。

来自：beefsteak

beefsteak — Fri, 05 Sep 2008 00:41:09 +0000

老鲍此言“I think the library AP gets it wrong anyway”说的是什么意思呢？是DC-lib的DC metadata element set还是library-related applications and projects？K师明示啊。

评论：DC-Lib应用纲要错误一例

来自：平台江

来自：keven

来自：beefsteak