元素名前缀的作用
谢老师的又一段评论被”关”起来了，现在放出来，并就自己的理解，加一点看法，同样不一定正确，望继续批评指正：
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在哪里解析的问题。
谢老师的评论主体（斜粗体为我的评论）：
说到上面的DC元素名要不要翻译的问题，我突然想到一个相关的问题，请教一下各位：
如果一个XML文档中有如下的片断
…
＜metadata
xmlns:dc=”http://purl.org/dc/elements/1.1/”
xmlns:dcterms=”http://purl.org/dc/terms/”＞
＜dc:title＞
UKOLN
＜/dc:title＞
…
我现在知道title是在名字空间”http://purl.org/dc/elements/1.1/”下的一个XML元素名。
也可以说此定位信息包含二元组：
title+”http://purl.org/dc/elements/1.1/”
~~~
下面我和大家开一个玩笑，请不必吃惊：
…
＜metadata
xmlns:dcterms=”http://purl.org/dc/elements/1.1/”
xmlns:dc=”http://purl.org/dc/terms/”＞
＜dcterms:title＞
UKOLN
＜/dcterms:title＞
＜dc:alternative＞
UK Office for Library and Information Networking
＜/dc:alternative＞
…
（dc:alternative并不存在）
请注意在这个例子中，二元组：
title+”http://purl.org/dc/elements/1.1/”
同样唯一、准确地标定了那个title。
不要被prefix所迷惑，那不过是简单指代namespace URI的一个设施，其字面是什么是没有关系的。当然，一般情况下除了像我这样开玩笑以外，没有人会把两个重要的namespaceURI的prefix互换 — 这会让人暂时被迷惑一下。
这样似乎是想说明如果要”翻译”prefix是没有问题的。别”翻译”URI本身就可以。
~~~
我从RDF Schema中看到，标定title元素是用
http://purl.org/dc/elements/1.1/title
这似乎是title本身的URI？
(对RDF Schema我不了解，所以发问)
而在最上面的XML文档中，我们只看到了title元素的prefix的namespaceURI:
http://purl.org/dc/elements/1.1
在XML以及XML Schema中，是否能够把prefix的URL和名称相接，认为
http://purl.org/dc/elements/1.1/title
就是title本身的URI?
也就是说二元组加起来成为一个完整的路径理解。
（以上我认为没错）
印象中，可惜的就是，XML文档中并没有设施来允许定义”元素名”本身的URI(上面说的namespace URI是prefix，或者说一层环境”空气”的URI，而不是元素名的。可以理解为元素名所在”目录”的URI，一个上层URI)，如果允许的话，那翻译的元素名的做法确实可以成功，因为可以想办法让最后起作用的(合成后)URI和DC的正式URI钩上。
不过在我以前的印象中，觉得namespace URI应当理解为不透明的，唯一标定一个东西就可以，没有想到上面猜测所涉及到的URI变得透明了(有内部结构有特定意义，类似文件路径概念)这个问题。
~~~
以上是我的问题。
如果确实可以像上面那样理解(合成URI)，那么当计算机遇到一个
…
＜metadata
xmlns:dc=”http://purl.org/dc/elements/1.1/”
xmlns:dcterms=”http://purl.org/dc/terms/”＞
＜dc:题名＞
UKOLN
＜/dc:题名＞
…
文档内容的时候，就会组装出下面URI来试图和所谓title的URI建立联系：
http://purl.org/dc/elements/1.1/题名
但是我们知道相应的Schema中肯定不存在对应于这个URI的东东，最终计算机就”理解失败”。
当然，如果为此(翻译问题)扩充Schema那效果另说。
谢涛 Said on 十二月 6th, 2007 at 4:23 下午 quote
keven老师说：
“3、正如远洋老师前面说到过的，dc:alternative这个元素是不存在的，alternative只存在于dcterms中。”
如何说起这个话题的呢？难道是因为我弄的那个玩笑例子的缘故？
…
＜metadata
xmlns:dcterms=”http://purl.org/dc/elements/1.1/”
xmlns:dc=”http://purl.org/dc/terms/”＞
＜dcterms:title＞
UKOLN
＜/dcterms:title＞
＜dc:alternative＞
UK Office for Library and Information Networking
＜/dc:alternative＞
…
远洋 Said on 十二月 6th, 2007 at 9:22 下午 quote
这一条是前几天说的，针对refinements是不是独立存在的properties，那时还没预见谢老师会开这个玩笑。也许谢老师正是因为见到那个讨论才想起来弄个小幽默的吧。
前缀的使用十分重要，比如关于title，没有前缀就乱套了（借秦健老师给的例子）：
catalog.xsd –> title of a book
journalIndex.xsd –> title of a journal
articleIndex.xsd –> title of an article
employee.xsd –> title of a position
autoInsurance.xsd –> Ownership certificate
注：这些是杜撰的xsd。 但是在真实工作中，这是存在的。比如LOM(Learning Object Metadata) 要求在给编目人名和评论人名时都要求用vcard (e-business card) 的元素，其中有一个元素是关于人的职称(vcard:title)。 同一个记录中，学习物件本身是有title的 (lom:title)，只有当这些title都带着QName, 才不会混淆。
平台江 Said on 十二月 6th, 2007 at 11:23 下午 quote
嘿嘿，我们刘所眼力不济，被谢涛的障眼法骗了，害得刘所针对谢涛的帖子发出了如此的评论：“dc:alternative这个元素是不存在的，alternative只存在于dcterms中”
这句话，放在之前的语境或上下文中说是正确的，但是，请看谢涛同志贴出的如下代码：
<metadata
xmlns:dcterms="http://purl.org/dc/elements/1.1/"
xmlns:dc="http://purl.org/dc/terms/">
<dcterms:title>
UKOLN
</dcterms:title>
<dc:alternative>
UK Office for Library and Information Networking
</dc:alternative>
他是把常见的dcterms和dc命名空间前缀绑定颠倒过来，所以他开玩笑的代码中的dcterms:title等于先前我们谈的dc:title，其dc:alternative也就等于先前我们谈的dcterms:alternative。
没有看出他这个障眼法，对于理解他想表达的意思会有些障碍。
下面，我又开始横向思维了:-)
谢涛同志弄出的dcterms:title和dc:alternative，粗看起来不是DC，但其实是等价的，正确的DC定义。而某些看起来象DC的应用，我是说应用而非语义定义，看起来是DC，但推敲起来总有点违背DC的原则（比如向下兼容或元素及其限定关系表达）。
DC不关心编码，并不意味着可以乱编码。我认为不能表达向下兼容或元素及其限定关系的编码都是不合理的。
因为，为什么现在采用XML作为元数据的编码达成广泛共识，就是因为XML作为一个立体的数据表达结构，它可以表达出比平面线型数据结构更复杂的关系。如果我们忽视这一点，那么，用XML与用ISO2709格式没啥两样——简单地说，MARCXML并不因为它采用了XML格式，就比ISO2709高级。
不是特别赞同只有RDF才能表达语义说法，理由如下：
1、假如我把一个大家觉得非常表达语义的RDF（XML编码）的命名空间甚至是元素名与属性名改成别的，这时候，其XML结构仍保持不变，对于计算机来说，处理起来有难度吗？
如果这样，改变了命名空间甚至是元素名与属性名的“RDF”就是一个纯粹的XML，所以说，XML能表达RDF欲表达的“语义”——简单地说，RDF的推荐编码也是XML，因而，迷信RDF是语义最佳编码是不妥的——谁敢说不会有人或团体利用XML，确定一种比RDF更合理的结构？
2、当然，RDF现在的地位不用置疑，并非是其编码无限合理，而是因为认可度高——只要广泛认可，就能满足交换目的，那么，它的价值和地位就得以奠定。ISO2709现在看来局限性那么大，但它的历史功绩却不容抹煞。
3、为什么RDF能达到广泛认可呢？是因为它的结构与定义约定俗成，这个约定俗成并不是因为大家高唱重大意义形成的，而是因为可以用RDF Schema进行表达，这种表达可以被计算机无歧义识别，所以可以实用化而非理论空谈。其实，不仅RDF Schema可以实现RDF的定义和约束，XML Schema一样能实现RDF的约束。所以，严格意义上，凡能被约束的XML，都能让计算机准确识别，从而表达出应用所谓的语义。
4、其实，RDF有其局限，除了需要定义对象和属性外，还需要定义复杂的陈述，这种复杂性导致开发成本和数据制作成本的加大。而RDF Schema也是一种类似二维表的定义来约束RDF词汇集。所以，更具立体结构定义的XML Schema可以定义和约束出远比RDF更复杂的数据结构并且不会产生歧义。
所以，历史赋予了RDF使命，并不是因为它高贵的体格，而是因为在没有更好的、更规范的数据结构定义时，它站了出来。
好比我看DCMI中某些编码指导时，总怀疑是否当时探讨编码时，众多语义专家无法承受这种计算机化的差事，把责任推到一个人手上——于是，这个执笔者及其编码思路就这样机缘巧合，凭借DCMI的影响力而具有特殊的地位了。
虽然有点对专家大不敬，但不妨碍我认为标准和规范，有总比没有好的观点。
keven Said on 十二月 7th, 2007 at 12:09 上午 quote
哦，多谢江先生的解释，我还真没注意谢先生的把戏。因为本身XML命名域只要是URI就可以，只是用作标识符而已，并不真的用作QName的合法性检验（好像书本上是这样说的），因而也就不去管这个声明是不是实际存在了。看走眼了。
keven Said on 十二月 7th, 2007 at 12:41 上午 quote
RDF肩负表达语义的历史责任，在我看来正是由于它的上帝（人）就是这样设计它的，天生用来表示三元组，来描述主谓宾的逻辑结构。在这一点上，RDF Schema和RDF的关系与XML Schema与XML的关系显示出了很大的不同，RDF Schema只是对RDF词表的扩展，而XMLS则是对XML文档的定义和约束，RDF可以看成RDFS的一个子集，而XML离不开XMLS的说明和限定。