DC-Lib应用纲要错误一例
马上要召开DC-2008了，DC的邮件列表里又热闹起来。今天的一个帖子说到DC-Lib应用纲要的问题，让我想到最近有人建议尽快将DC修饰词和领域应用一并推向国标。愿望很好，但其实国内对DC元数据的应用还没有形成一种讨论的氛围，许多人都回避讨论，只想交给一些“伪精英们”（也算包括偶吧）制定出来执行就完了，其实这样是无法形成对一些问题的基本理解的，即便推出一个“正确”的国标，也恐怕会因为理解的不同而无法执行，何况对于我们来说做到“正确”是何其困难！前一阵与平台江和谢涛君的争论就很好，“我国数图标准规范研究”项目组内部不多的争论也很好，只是太少了。问题不摆到台面上公开讨论，就为以后大家阳奉阴违埋下伏笔，这是对标准化事业最大的伤害。
问题是这样的：在DC图书馆应用纲要中对于“格式（Format）”的修饰词“媒体(medium)”有一段说明：
Used to specify the medium of the physical carrier of a resource. Format without an element refinement qualifier should be used to specify the electronic format of the resource, using the encoding scheme IMT. Format should be repeated if both are applicable (e.g. a PDF file on CD).
用来特指资源物理载体的媒介类型。“格式”如果不带修饰词，则应该采用IMT（即MIME的格式词——keven注）的编码体系修饰词作为取值，特指资源的电子形式。如果即有电子格式又有物理类型（例如放置于CD上的PDF文件），则应该重复著录。
这段说明完全违反了DCAM（DC元数据抽象模型）所规定的1:1原则，因此是完全错误、应该被修正的。可惜DCMI许多文档的修订工作根本就跟不上。
Andy Powell对这个问题的回答很有意思：
Firstly, dc:format is a total mess. (I guess you knew that!)
Secondly, I think the library AP gets it wrong anyway
…….
Sigh… disclaimer, I chaired the original dc:format working group and hence share some/much of the blame for the mess – but I think it was a mess way before then anyway
当然，Andy也给出了这个问题的解释：
dcterms:medium只能用于描述资源的物理形态（格式），这在抽象模型的domain-range中说得很清楚了。因此dcterms:IMT不能用于修饰dcterms:medium，只能修饰dc:format或dcterms:format。
据此，就不存在重复元素/子元素问题了（因为描述电子格式和物理格式的元素/子元素是不同的）。
Powered by ScribeFire.
Popularity: 53% [?]
beefsteak Said on 九月 5th, 2008 at 8:41 上午 quote
老鲍此言“I think the library AP gets it wrong anyway”说的是什么意思呢？是DC-lib的DC metadata element set还是library-related applications and projects？K师明示啊。
Like or Dislike:
0 
0
[回复]
keven Said on 九月 5th, 2008 at 9:00 上午 quote
DCMI的Application Profile是特指DC元数据在特定领域应用的规范方案，DC-Lib就是指DCMI的图书馆应用工作组在很多年前就开始讨论和研发的一个AP(应用纲要)，即文中有链接的那个。这两年这个项目似乎停顿下来，倒是后提出的一个“资源集合”的AP先行推出了，目前已经是DCMI的推荐规范了。
老鲍的意思是说当初这个工作组理解错了，他自己曾经做过这个组的主席，因此他说他也有责任，但是这个错误不是他的任期内产生的，他只是没有纠正而已。
现在DCAM成为DC所有应用的纲领和原则，所以凡是与此相违背的，都是要被抛弃的，呵呵。
感谢留言。
Like or Dislike:
0 
0
[回复]
平台江 Said on 九月 24th, 2008 at 1:50 下午 quote
好久没来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元素的东西，编码体系限定与语义修饰限定间没有任何关系。或者这样表达：编码体系限定是限定元素或限定被语义修饰词限定后的元素。
那么，要想形式化表达清楚这种关系，可以这样来：
<dc:format></dc:format>
可以视之为隐含或忽略了编码体系限定的编码方案，它与下面显式声明了编码体系限定的编码方案是等价的、结构一致的：
<dc:format xsi:type=”dcterms:IMT”></dc:format>
假如忽略语义限定词，采用IMT编码方案限定，合法的描述应该是这样的：
<dc:format xsi:type=”dcterms:IMT”>application/pdf</dc:format>
之所以说它是合法的描述，是因为声明采用dcterms:IMT编码体系限定，那么描述值就应该是采用这个体系中的合法值“application/pdf”。它等价于显式声明语义限定词后的编码方案：
<dc:format refiniment=”dcterms:medium” xsi:type=”dcterms:IMT”>application/pdf</dc:format>
有趣的事情来了：
假如这样来表达：
<dc:format refiniment=”dcterms:medium” xsi:type=”dcterms:IMT”>aabbcc</dc:format>
从数据规范来讲，描述信息是错误的。aabbcc是啥玩意儿？因为在dcterms:IMT编码体系中，没有这玩意儿的定义！但从元数据编码方案来看，形式上是没有错，语义上也没有错，都表达出了“资源的Internat媒体类型是某某某”的概念——至于aabbcc是什么媒体类型，那是另一回事了。这也是一种挂羊头卖狗肉的作法：我声明我采用dcterms:IMT规范词汇来描述资源的载体格式，你们就要当我是采用这个编码体系。至于是否允许我随意录入描述词汇或先占个位，以后再改正，这就是数据制作过程中，通过系统或规章制度来控制与防范的事了。
所以，“DC图书馆应用纲要”中对“格式（Format）”的修饰词“媒体(medium)”的说明中，除了违背了1:1原则外，所谓：“格式”如果不带修饰词，则应该采用IMT的编码体系修饰词作为取值，特指资源的电子形式”更应该是一种错误。照此说法，不带限定词的简单DC，除了采用IMT的编码体系修饰词取值外，就无法描述资源了？
难道只能有隐含IMT限定的是合法的：
<dc:format>application/pdf</dc:format>
或显式IMT限定的是合法的：
<dc:format xsi:type=”dcterms:IMT”>application/pdf</dc:format>
就不能有采用其它编码体系限定或根本不采用编码体系限定的描述？以下编码方案难道是错的？
<dc:format>牛皮纸</dc:format>
这似乎有违DC的Dumb Down原则——顺带求教一下，Dumb Down该翻译为“向上兼容”还是“向下兼容”？这个翻译结果有点相对论的味道，嘿嘿。
其实，“牛皮纸”与“aabbcc”，从客观语义（借用这个词汇不知是否能准确表达我的意思）来说，应该是等价的，都是采用某个字符对资源的格式进行的某种描述。至于这两个不同的描述值的主观语义，在特定的环境中，它们可以相同、也可以不同——有点扯远了。
由于多见这样的编码方案：
<dc:format></dc:format>
<dcterms:extent></dcterms:extent>
<dcterms:extent xsi:type=”特定的编码体系”></dcterms:extent>
<dcterms:medium xsi:type=”dcterms:IMT”></dcterms:medium>
把元素语义限定等同于元素一样表现为XML的元素，但又不得不把dcterms:medium和dcterms:extent与dc:format捆绑在一起宣传——不捆绑起来，如何体现口口声声中的元素及其语义限定的DC概念呢？
这个时候，才有什么“格式”如果不带修饰词，则应该采用IMT的编码体系修饰词作为取值的解释了，本来不是问题的问题，这么一解释，反而让人更糊涂了。
Like or Dislike:
0 
0
[回复]