谢老师的又一段评论被”关”起来了，现在放出来，并就自己的理解，加一点看法，同样不一定正确，望继续批评指正：

1、类似dc:title这样的元素名前缀我一直以为是不可缺少的，即在编码时dc与title共同组成一个有意义的XML元素(或属性)。
2、因此可以认为dc:title和dcterms:title是完全不同的，其相等关系隐含在DCMI的其它声明中，或者通过应用系统建立。
3、正如远洋老师前面说到过的，dc:alternative这个元素是不存在的，alternative只存在于dcterms中。
4、命名域xmlns指定了前缀的参考地址，使得元素具有了全域的唯一性，起到的作用正是谢老师在下文中所说的目录指向，只不过在广域网环境下、采用了URL的指向。
5、因为这里RDF是用XML来表达的（也可以用N3或者DC自己定义的DC-Text来表达），所以尊崇XML的所有的规定和语法，包括命名域和前缀的规定。
6、对于名称和翻译，我在深圳的报告 ppt第23页有一个盗版Stuart Weibel的图（如下），应该能够说明翻译的label在哪里解析的问题。

谢老师的评论主体（斜粗体为我的评论）：

Read the rest of this entry »

更新update: 远洋老师的另一个示例文档已经提供下载。昨天为了这些代码折腾了一个多小时，本来前面还有一大段话，一发布就都飞了，可能是因为代码中除了包含<、>之外，还有其它trick，抑或因为wordpress的bug（太长？）。大意是说，Leon提醒我XMLS的关系描述能力有限，需要描述语义层次关系恐怕还非得RDF，令江汇泉抓狂的原因恐怕就在这里，而不仅仅是DC的属性词表不够，等等。

远洋老师给的DC元数据编码示例（另一个例子实在没法放到博客上，您可以在这里下载）：

Read the rest of this entry »

江汇泉老师在我的上一篇帖子中留了一个关于DC元数据XML模式的深度讨论，非常好的一个帖子，不知为什么被列入了“待审核”评论中，所以今天才得以“解放”，抱歉一个。后面谢涛老师的系列讨论，思路清晰，论述精彩，强烈推荐！因此给予“特殊待遇”，单列此帖。（顺便一说：本人的这个博客可以自由注册，如果需要单独展开议题，注册后应该即可发帖，如有问题请留言或发email。）

看完几位老师的留言，除了下面拉拉杂杂的留言之外，希望大家能够多关注并仔细领会DC元数据抽象模型，以及基于这个模型的新的编码规范的讨论（参见Expressing Dublin Core metadata using XML，以及DCMI Architecture Wiki）。同时希望共同探讨：独立与信息系统的、基于RDF/OWL描述的“语义层”是否有可能单独建立，从而使得应用系统的功能实现（如检索、浏览等）与内容描述完全分离？

江老师的原帖如下（同样，粗斜体为我的评论）：

Read the rest of this entry »

警告：慎入！这个帖子会很长，主要涉及元数据编码细节的讨论。

承蒙谢涛和江汇泉两位技术大拿与远洋老师在我的博客上发起了热烈的讨论，所涉及的问题实在是在实践中非常重要，却很难武断地进行“推荐”。这里只能就我对DCMI编码的理解，夹叙加议，谈一点看法，希望国内这个领域的有识之士，例如参加过张晓林大组长标准规范课题的（像Leon、郑锡惠、徐周亚），以及CALIS国科图清华北大中科院等做过实践的，参与讨论。

本想在http://www.dublincore.cn/上讨论，但那是一个wiki，格式上不方便，这里讨论的结果将放到那边汇总。

需要说明的是，目前的“DC元数据XML编码指南”正在修订更新，将推出一个完全符合DCAM的规范，进行中情况请参见Expressing Dublin Core metadata using XML，以及DCMI Architecture Wiki 中的讨论(那里有大量的例子)。

摘要：

1、目前DCMI推荐的所有编码方案，均是尽可能遵循DCMI元数据抽象模型(DCAM)，DCAM是独立于编码、却为编码提供统一方案的数据模型。

2、目前争议的焦点实际上在于对这个模型没有透彻理解，以及对于基于XML、进而RDF的数据模型没有透彻理解。

3、XML的数据封装不能脱离XML模式（XML Schema或XMLS）或者DTD，也就是说所有包含XML实例序列化的数据原则上都需要XMLS或DTD才能让计算机读懂。而目前我们XML举例时通常直白地直接列出元素，似乎无需XMLS进行元素及结构的解析。这是不严格的。

4、因此DC元数据的XML表达（包括RDF表达）从数据上看起来是平面的，但是其结构和语义是用XMLS来约束的（如果是RDF，扩展的元素用RDF Schema进行定义），因此不能认为它是平面的。

5、这也就是说，DC元数据的形式化描述中，dc:alternative看起来与dc:title处于一样的地位，但实际上是完全不一样的，在XML文件的根元素指向格式解析模式中（通常是一个形式化的元数据应用纲要），可以明确它们的上下位关系，通常在如下的文件中规定格式：
<xsi:schemaLocation=”http://example.org/mydiglibapp/ http://example.org/mydiglibapp/schema.xsd”>

6、应用系统在实现功能时，不应脱离XMLS去读XML文件。

7、拼音的编码方法：按照以前的做法（目前并不推荐），可采用修饰词的方式在XML中编码，如<title.transcription>bo po mo fo</title.transcription>。Akira在文章中给出了抽象模型的表示：

Statement (
PropertyURI(dc:title)
ValueString(汉字表示)
)
Statement(
PropertyURI(dc:title)
ValueString(Bo Po Mo Fo)
)
……

根据目前DCMI同行的做法，我猜想应该采用重复元素（字段），对属性值扩展Scheme词表的形式来说明，如扩展书写方式scheme为包含pinyin, hana, hanja, kanji…等编码的词表：<dc:title Scheme=”yournamespece:pinyin”>Bo Po Mo Fo</dc:title>（如果词表有名称并需要标注的话，则编码稍微复杂些）。在正在酝酿的新推荐方案中，规定了封装的容器，弄得很复杂。

8、RDF编码的意义（完成中…）。

以上是我的理解和解释的大概。

以下是谢涛和江汇泉两位老师在我上一个帖子后的留言，干脆移到这里，并加上我的粗斜体议论（不断增加中）。（由于原文中许多代码含有<和>，拷贝粘贴时被浏览器吃掉了，我这里恢复的不一定正确，如有误请更正）

江老师留言1：

Read the rest of this entry »