代码示例1
更新update: 远洋老师的另一个示例文档已经提供下载。昨天为了这些代码折腾了一个多小时，本来前面还有一大段话，一发布就都飞了，可能是因为代码中除了包含<、>之外，还有其它trick，抑或因为wordpress的bug（太长？）。大意是说，Leon提醒我XMLS的关系描述能力有限，需要描述语义层次关系恐怕还非得RDF，令江汇泉抓狂的原因恐怕就在这里，而不仅仅是DC的属性词表不够，等等。
远洋老师给的DC元数据编码示例（另一个例子实在没法放到博客上，您可以在这里下载）：
<rdf:Property rdf:about=”http://purl.org/dc/terms/alternative“>
<rdfs:labelxml:lang=”en-US“>Alternative</rdfs:label>
<rdfs:commentxml:lang=”en-US“>Any form of the title used as a
substitute or alternative to the formal
title of the resource.</rdfs:comment>
<dc:description
xml:lang=”en-US“>This qualifier can include Title
abbreviations as well as translations.</dc:description>
<rdfs:isDefinedBy
rdf:resource=”http://purl.org/dc/terms/“/>
<dcterms:issued>2000-07-11</dcterms:issued>
<dcterms:modified>2002-06-15</dcterms:modified>
<rdfs:subPropertyOf rdf:resource=”http://purl.org/dc/elements/1.1/title“/>
<dc:type rdf:resource=”http://dublincore.org/usage/documents/principles/#element-refinement“/>
<dcterms:hasVersion rdf:resource=”http://dublincore.org/usage/terms/history/#alternative-002“/>
</rdf:Property>
远洋 Said on 十二月 5th, 2007 at 3:19 上午 quote
Thanks, Keven.
以上节选是DCTERMS 的 RDF Schema中来的，要点在这一条中的 “subPropertyOf “ 上–显示alternative与title的关系:
< rdfs:subPropertyOf rdf:resource =" http://purl.org/dc/elements/1.1/title "/>
在DCTERMS 的XML Schema 中，是靠 “substitutionGroup”来显示其与title的关系的: <xs:element name="alternative" substitutionGroup="dc:title" />
schemas: http://dublincore.org/schemas/
谢涛 Said on 十二月 5th, 2007 at 10:02 上午 quote
回远洋老师：
是的，从RDF schema中能看出alternative和title的关系。
无独有偶，非常凑巧，昨天我还在一封email中引用了类似RDF schema的细节，那是为了给DC的元素名在中国国标中要不要翻译，或者拉扯进来说要不要翻译DC元素的label而提供一点证据。
摘录如下：
…
其中可以看出，label和comment内容都是有语种特征的文字内容，如果将来增加了中文版本，可以这样增补内容：
〈rdfs:label xml:lang=”en-US”〉Title〈/rdfs:label〉
〈rdfs:label xml:lang=”zh-CN”〉题名〈/rdfs:label〉
〈rdfs:comment xml:lang=”en-US”〉A name given to the resource.〈/rdfs:comment〉
〈rdfs:comment xml:lang=”zh-CN”〉资源的给定的名字。〈/rdfs:comment〉
(description也一样)
而抽象的title元素本身，是一个抽象的概念，是无所谓语种，如果非要说有(表达的需要)，那就只能是采用中立语言(英文)的这样一种。
在编码层面，DC元素必须要有一个名字，这个名字应当是中立语言的。
~~~~
这里使我想起一个很有意思的相似性：
科技部课题组把DC元素的本名和label是否翻译的事情搞反了，本名去翻译，label反而不翻译，这有点像某些人开国际会议时候一样，明明在中国开，参会的中国人多，该说中文的场合，它却要说英文。这和DC元素名是否要翻译问题的搞反，其实是一脉相承的。
…
注：后面的玩笑不必当真，纯属横向思维，那原本是江汇泉的擅长和专利…
谢涛 Said on 十二月 5th, 2007 at 10:33 上午 quote
接着说DC元素名要不要翻译的问题：
别的方面不说，就说DC元素名用在XML编码方面，如果XML中的元素名用中文，那么和英文就不是一个东西了。那么，原本期待去读英文元素名的程序，看到中文的元素名就根本不去理会，这样的“用于交换的数据”根本没法交换。
这里也顺便请教一下江汇泉，用“中文元素名”的XML文件，何以通过那给定的Schema校验呢？如果为此要另外开发一个Schema，那中国国标的所谓DC就不是和DCMI的DC等同的标准了，而是另外一个标准了。听了一耳朵江汇泉说的什么 — 盗版DC。
开个玩笑，URI是不是要翻译呢？例如：http://purl.org/dc/elements/1.1/title
毕竟里面出现了一个title。
这都是些匪夷所思的念头。
~~~
这使我不禁联想起多年前国家要推行什么GB18030，说也是一个国际大字符集的编码标准，但是却和UTF-8不一样，据说吸取了和UTF-8一样的“技术”。既然是国家标准，就有强制力，有关部门因此勒令当时“不符合标准”的Windows 98下架不准销售，直到Microsoft赶紧开发出一个补丁模块，为windows 98增加了相应的API。
结果没有几个人真用这个GB18030。
~~~
还联想到ISO2709面对的新课题：最早ISO2709是针对ANSI字符集的，类似GB2312这样编码方式没有问题。因为英文部分都是8-bit的ASCII码，头标区和目次区没有问题。
也可以说，即便是美国人编写的不支持汉字的程序，读入ISO2709的结构没有问题，虽然可能不能辨识其中的汉字编码(其中的英文尚能辨识)。这是一种形式上的规则，一种二进制兼容性要求。
后来Unicode应用后，出现了多种编码方式，例如UTF-16和UTF-8等等。UTF-16显然不能用在ISO2709上，因为头标区不再是24byte，而是48byte，这样就破坏了ISO2709的形态规定。实际上UTF-16编码的所谓ISO2709文件，旧软件一定是装不进去的。
UTF-8很有意思。据说这是一个大毕业生的论文，它是一种横跨两极，亦ANSI亦UNICODE的编码方式。从形态上看，UTF-8中的英文部分，还是一个字符一byte，而中文和其他一些语种部分，是3-6bytes不等(注，不仅仅是3bytes，这是一个误会)。这样，UTF-8编码的ISO2709，从物理形态上完全可以被旧软件接受，虽然这些软件可能不认识里面的中文等编码，但是毕竟能装入系统了。而且大部分这样的系统，对于文字字符串能够存储即可实现基本功能，不一定要求它们可以理解里面字符的边界。(例如C语言的编译器软件，只需要理解C的保留字 — 它们正好是英文，而字符串常量等，编译器将之原样pass到后一环节即可，不一定要“理解和翻译”)
UTF-8编码的ISO2709，当然可以被新一代的认识这个编码方式的软件全盘接受，包括理解里面的汉字字符。
所以，UTF-8是一个好聪明的编码方式。从形态上看，你把它当作一个ANSI类编码方式来看待和处理，一点没有问题。
这个例子说明了一点，要应用一定要真去用，或者脑子里有走到那个环节。UTF-16确实没有办法用在老ISO2709定义上。这是无需争论的，你拿着一个这样的文件往老系统里面转入一下就明白了。
~~~
抱歉，扯到另外一个话题上了。
远洋 Said on 十二月 5th, 2007 at 11:00 上午 quote
是啊，我们也很久都没领会DC用name和label的意思。不与schemas和namespaces打交道可能永远不会重视这些。
谢老师说的元素的抽象概念，说得非常好。在语义网中要解决的一个问题，就是要将概念本身（不管是人是物是时间还是事件）与其称谓分开。多语种对照的元素集、词表、权威控制档等一般都是在名称上的工作，但若牵涉概念的变化和概念的关系则应是在概念上的工作。
三言两语很难说清楚。江老师和谢老师在北京还是上海？如果有机会Keven可以组织大家12月中一起交流一下, (不算国际会议，大家都用中文）。
话说回来，只要是叫‘国际’会议, 论文集还是要用英文的，只要有一个老外在场，会议就应用英文（或者规定的文种）。而且，如果大家慢慢习惯了，双语都流利了，今后的交流和阅读就要方便得多。
谢涛 Said on 十二月 5th, 2007 at 3:24 下午 quote
回远洋老师：
我和江汇泉都在北京。
我的关于“国际会议”一个玩笑开得有点过火。幸好远洋老师很有幽默感。我不是反对使用英文开会(尽管我的英文很差)，而是想表达点别的意思，不过实际没表达出来。
说到上面的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＞
…
请注意在这个例子中，二元组：
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 十二月 5th, 2007 at 3:37 下午 quote
一点感想：
这个博克不允许在文字中出现大于号、小于号，说明这博克软件(WordPress?)多么业余。一般而言，是软件直接把post上来的正文当作最终的HTML字符串发给浏览器了，没有HtmlEncode()一下。（本博克是不是这样没有来得及验证 — 怕把博主这里搞乱了）
还有一种可能就是见到大于小于符号就简单过滤掉。本博克好像不是这种，因为显示出来后的效果是属性字符串不见了。
如果真是这样，那很有危险的：用户随便post上来的东西，被当作HTML指令使用 — 好比当作“刀”。HtmlEncode()的作用就是把文字让文字 — 好比当作“肉”。所谓危险就是，post上来的含有一些刻意的scripting代码什么的，被当作真正的HTML代码发给浏览器，就可以做点恶作剧什么的了。
对这个缺陷的一个规避办法，目前我是用全角汉字符号替代西文大于小于号。
谢涛 Said on 十二月 5th, 2007 at 3:40 下午 quote
刚看到博主注解的“大意是说，Leon提醒我XMLS的关系描述能力有限，需要描述语义层次关系恐怕还非得RDF，令江汇泉抓狂的原因恐怕就在这里，而不仅仅是DC的属性词表不够，等等。”
这个大话题是不是和我上面提到的“名字空间字符串”小问题有一点点关系呢？
小钟 Said on 十二月 5th, 2007 at 4:36 下午 quote
学习。
keven Said on 十二月 5th, 2007 at 5:55 下午 quote
我的理解：支持用户代码正是wordpress刻意选择的，虽然有风险，但却支持了开放性，使得博客平台很好玩，而不是像国内的许多BSP那样，对自己的技术那么不自信。希望用<和>的毕竟都不能算菜鸟了，自然能够想办法达到他们的目的。
那段话主要指江大侠说<xs:element name=”alternative” substitutionGroup=”dc:title” />不能表示两者之间的层次关系，而RDF可以表示，以及还有许多其它关系约束和定义能力方面的不同。
谢涛 Said on 十二月 5th, 2007 at 6:27 下午 quote
回keven老师：
如果博克里这个唯一的文本框意思是HTML代码框，那倒是有你说的优点了。
不过系统仍需要对post上来的代码进行检查，这不是“自信”的问题，里面风险很大(虽然不至于把服务器搞坏，但是会把看帖子的用户的浏览器和本机操作系统搞坏)。
一般的做法，是分为两个编辑器：一个是纯HTML的(里面输入的文本被直接当作HTML使用)，技术专家可以用；另外一个是所见即所得的(支持一定的格式排版)，一般用户使用。或者组合起来用tab标签切换。
两边来回切换，还可以互相参照。
如果只有一个文本框，那一般来说，不特别说明，用户肯定以为是纯文本框，不会想到居然是HTML代码框。
而像本博软件这么做的，就还处在原始社会了。
~~~
原来了解一点keven老师的博克多次搬家的情况，深表同情。不知这个dlresearch是不是您自己的服务器呢？如果是自己的服务器，那就算自己的家了，自己说了算。
~~~
一直想说，…今天就说：有空可以看看网易的博克，
http://blog.163.com
如果有闲功夫可以去那里注册一个空间，试用一下。
它是采用了AJAX技术的。当然是不是采用这个技术，我倒是觉得不太重要。如果要时髦，采用了也不错。我感觉很满意，我以一个开发人员身份隆重推荐。
不过我没有太多用FireFox浏览器测过它。印象里好像是没有问题的。
keven Said on 十二月 5th, 2007 at 6:43 下午 quote
wordpress在博客编辑界面是提供了两个选项的，您可以注册一个用户，进去试试。另外wordpress支持各种插件和sidebar，这些都需要能够运行用户代码。当然评论筐“缺省”也支持代码，不知道有没有什么安全措施，我相信应该是有的，我用下来一直没发现什么问题（除了与ie有的时候不兼容）。目前这个博客确实是建立在办公室的服务器上，所以灵活度大些。网易的博客平台确实是非常不错的，我曾经推荐我女儿和她的同学在网易上安家，因为感到那里更加风花雪月一些。
远洋 Said on 十二月 5th, 2007 at 10:41 下午 quote
很对不起让Keven花这么多时间在贴这些code上，当时以为他可以就作为图片贴上来。
我的理解：只要是HTML/XHTML的浏览器，都必须遵从根据SGML定义的entities，对特定字符用代码表示 （所以我们的code不能显示）。例如对版权符号可以用代码“©“或者数字”©” 两种方法表现。
这是根据HTML4中对版权符号的定义来的：
<!ENTITY copy CDATA “©” — copyright sign, U+00A9 ISOnum –>
XHTML沿袭HTML4的代码字符集，见： http://www.w3.org/TR/REC-html40/sgml/entities.html
我估计没有哪个博客工具能让我们直接贴code上来。当然有些 blogs工具（如ning)允许显示和编辑html code。
教学用的大型网络教学系统如WEBCT, VISTA也都有类似的问题。 所以当学生要上交code时，总是必须将大于小于号变成entities代码。或者上传一个附件。
tips: 如果要在Keven这里的blog上post大量的编码，可以先在一个html editor（例如Dream Weaver， HomeSite)上将编码贴成 text, 再看source code时，大于小于号等就自动变成正确的entities了。然后再贴到这里来。
远洋 Said on 十二月 5th, 2007 at 10:46 下午 quote
又遇到同样的问题了。上贴中的© 是“&”加上分号“；”再加上“#169“。 这次Dream Weaver也没用了，还没找到更好的办法。
平台江 Said on 十二月 6th, 2007 at 1:47 上午 quote
今天忙“业务”一整天，都顾不上来此地儿扯理论了——比不上刘所、远洋师等——你们整这些理论反而是正事，羡慕……
远洋师如果12月中旬来北京，只要我没到外地跑“业务”，定当面听教诲。
注：重庆“棒棒儿”称所找到的苦力工作为“业务”
谢涛 Said on 十二月 6th, 2007 at 11:53 上午 quote
回keven和远洋老师：
网易博克表面上“风花雪月”，但是骨子里技术很高强、正统，在各个大门户网站中，网易博克是后来者，只能以技术取胜。
具体来说，post上去html或者xml代码，那里就不是问题。
~~~
远洋老师说“我估计没有哪个博客工具能让我们直接贴code上来”，印象中网易就可以呀，许多博克都可以。
这里的道理很简单：软件把这些代码当作“文字”而不是html或者xml代码就可以了。服务器端发出来前，htmlencode()一下就可以了。
至于“可以先在一个html editor（例如Dream Weaver， HomeSite)上将编码贴成 text, 再看source code时，大于小于号等就自动变成正确的entities了”，那是您老人家替处于“原始社会”的服务器端软件做了它原本该做的操作而以。
“当然有些 blogs工具（如ning)允许显示和编辑html code”这个和“允许把html或者xml代码作为正文贴上来”没有关系。
比方说左边是一个“text窗”右边是一个“html code窗”，您要post上来html代码，让别人看这些代码，进行学术研讨，您一定是paste到左边而不是右边。如果您是一个技术高手，想直接编写html代码而形成某种效果，想让别人看到这些代码的“显示效果”，那您应该把这样的代码paste到右边，对不对？
当然这样的左边、右边界面，本身就是一个html效果和代码的翻译器，您把本来在右边的html代码copy后paste到左边，那意图就是想让别人看到赤裸裸的html代码。而这时右边的html代码中出现各种entities，那自然是对的，因为非如此不能达到让别人之间看到html代码本身的效果。
“教学用的大型网络教学系统如WEBCT, VISTA也都有类似的问题。 所以当学生要上交code时，总是必须将大于小于号变成entities代码。或者上传一个附件。”估计这些都是由于他们生活很朴素的风格形成的一种局面。咱们(许多)中国人开发软件，估计“服务性工作”会做得更好一些，不会出现这种朴素的场面。
谢涛 Said on 十二月 6th, 2007 at 11:57 上午 quote
顺便说一句：如果需要，我可以给keven老师和这里需要上贴html/xml代码的同志搞一个简单web界面encoder“器”，放在Internet上，大家要贴之间先去那里转换一下，便于讨论进行。
谢涛 Said on 十二月 6th, 2007 at 4:03 下午 quote
keven老师和远洋老师：
上面标有测试字样的comments请删除，那是我测试用的。
我花了一点时间编了一个html encoder小模块，在
http://dp2003.com/dp2portal/htmlencoder.aspx
使用方法：把html/xml代码paste到上方的textbox中，然后点“encode (nbsp)”按钮，下方textbox中就会出现encode以后的字符串，把它copy/paste到博克中，就没有问题了。
(encode按钮和encode (nbsp)按钮的功能区别，是在于前者没有encode空格，这样post到博克的文字就没有了原来缩进的效果了；而后者encode了空格，保持了缩进的效果)
那个word文件中包含的RDF schema，我也试验了一下，encode后post到这个博克，显示Your comment is awaiting moderation，我估计这是因为文本太大了的缘故。因为小一点的文本是可以上去的(虽然有时也显示Your comment is awaiting moderation，估计里面是有一些违禁的字眼？)
keven Said on 十二月 6th, 2007 at 5:25 下午 quote
非常感谢！我把这个帖子也移出来。