数图研究笔记 » 编码

元素名前缀的作用

keven — Wed, 05 Dec 2007 22:26:12 +0000

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

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那效果另说。

代码示例1

keven — Tue, 04 Dec 2007 13:51:23 +0000

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

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

<rdf:Property rdf:about=”http://purl.org/dc/terms/alternative“>

<rdfs:labelxml:lang=”en-US“>Alternativerdfs: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-11dcterms:issued>
<dcterms:modified>2002-06-15dcterms: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>

关于DC元数据的XML模式

keven — Sun, 02 Dec 2007 22:50:08 +0000

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

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

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

受刘所之命，移师此帖中进行讨论。
非常赞同应该关注XML Schema或XMLS的意见。先就之前话题的回复谈点看法，并在后面，详细分析DCMI的Schema。

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

我的看法：XML表达，从数据来看都是线型的。但线型的数据，可以简单表达一层或二层数据结构，也可通过嵌套，表达出立体的、多层结构。

从数据交换来看，离开了XMLS的XML是无意义的，即使同采用了dc:title这类DC名称，即使从数据样例来看完全一样，从理论上讲，也不能肯定其是完全一样的。只有符合同一个XMLS的约束和定义的数据，才能说它们是一致的。但并不能说因为采用XMLS约束了平面的数据，所以数据就变成了立体的而不是平面的。因为XMLS仅是对数据的一种约束和定义，数据是平面的，则XMLS就表达了这种平面结构的定义和约束，反之，则XMLS就表达了这种立体结构的定义和约束。（当然，表达立体、层次概念的XML Schema是一定能够表达平面关系的，dc.xsd就是这样。我的表达不严密，被纠住了辫子，呵呵）

针对“这也就是说，DC元数据的形式化描述中，dc:alternative看起来与dc:title处于一样的地位，但实际上是完全不一样的，在XML文件的根元素指向格式解析模式中（通常是一个形式化的元数据应用纲要），可以明确它们的上下位关系。”

我的看法：如果是当前DCMI推荐的限定性DC形式化结构，即dc:alternative看起来与dc:title处于一样的地位，那么，在XMLS中，也是一样的地位，而无法确定它们的上下位关系。这点我将在后面的XMLS分析中进一步说明。（看了你后面的说明，由于我的确没有对DC的XML编码进行过实践，看来你说的是正确的，即目前DCMI推荐的XML Schema中确实没有反映出dc:title和dc:alternative之间的上下位关系，但是就我从DCMI中得到的印象来看，这是不应该的，即XML Schema如果不表示出这种关系，它就无法实现dumb-down。我会就这个问题去问一下DCMI的相关人员。）

关于我所谓“总在语义层面中纠缠”的感慨，仅是从纯技术层面角度来看，信息编码的根本目的仅是为了让计算机更易识别，所谓可读性更主要是指数据结构清晰无歧义、计算机处理效率更高。而不是指标识符带语义以及这种结构表达出某种语义——因为这些东西是人为赋予它们的。

所谓语义，我看用鲁迅谈及《红楼梦》的一句话来评论比较贴切：“经学家看见《易》，道学家看见淫，才子看见缠绵，革命家看见排满，流言家看见宫闱秘事”——计算机将元数据编码组合后，它们表达的语义，完全视用户或行业的约定俗成而定罢了。我是赞成谢涛同志所谓“大家讨论的许多问题可能确实和编码层面无关。因此建议可以先把编码层的实践方向和细节搞清楚，从而就可以开始行动了，具体语义和如何细节著录的事情可以继续吵，但是软件纹丝不动”的观点。都没有一个确定的编码组合，何来语义？“我”、“爱”、“你”——没有一个固定的组织方式，那么可以表达出“我爱你”、“你爱我”甚至引申为单相思或两情相悦等多种语义。

当然，结构清晰无歧义的编码，可以帮助人们实现语义的表达，这就是我们追求某种合理的数据结构或数据封装的原因。

（RDF/S及建立在它基础上的编码，如OWL/S等，是专为表达语义和逻辑而设立的，当然，你说得没错，计算机是不懂语义的，计算机表达语义也是通过事先约定的属性和关系——可以定义为机器语义，计算机处理从以字符元素，到文档(XML)元素，到语义元素，在思想方法上是完全不同的，可能跳跃得快了一些，需要进行一下Paradigm shift。语义Web的基础技术，就是为了解决您举的《红楼梦》的例子所存在的问题，目前所做的，只是希望通过表达语义的约定，尽可能解决计算机之间的语义传递问题。从原理上来说XML/S是无法做到这一点的。James Hendler有一句名言：A little semantic goes a long way. 的确如此，许多搞计算机的并不理解这一点，而情愿不厌其烦地建造信息孤岛，永远做机器的奴隶。计算机高手们不认同，也是造成目前SW发展艰难的一个重要原因）

针对“这与目前成熟的计算机软件系统体系架构有关，具体的应用都要采用成熟的技术，因此直接用XML编码的应用很少，DC大多作为一种交换格式，于是编码的一致性就显得不是那么重要的，谁都可以自定义”

我的看法：正是因为DC大多作为或将要作为一种数据交换格式，那么强调编码的一致性就非常重要——这个编码并不是说系统内部存贮或编码格式，而是说输出或交换时的编码格式。所以，不管系统开发者采用或拙或巧的数据库架构，只要想交换，就得采用某种一致的编码方案。不管是采用先形成数据，再形成统一的编码方案，并以这种统一的编码方案转换和规整已有数据，还是先形成统一的编码方案，以这个方案指导产生数据，最终得有一个统一。DCMI并不关心编码，这是它想兼包并蓄的理想，但我认为具体行业应用时，还是得有一个可操作的编码方案。

（很高兴你们一直有这样的想法，这是一种远见，与我的观点没有不同，我只是说出了“其他人”的观点，呵呵）

好比不管如何批评MARC的落伍，起码人家有ISO2709、MARCXML这种编码方案，就省去了学术之争与技术实现困扰。这也是我寄望我们国标制订机构或行业专家们能给我们一盏明灯而不是让我们摸着石头过河的原因。

针对“推荐 DC元素与元素限定词都编码为XML元素，采用QName，通过所引用的namespace来隐含表达元素与限定词间的关系（正如后面谢涛所说，这样倒反而不是“隐含”，而是通过XMLS显式地定义。当然，只是说法而已）”

我的看法：我所谓的隐含关系是指——QName可以看作指明元素的命名空间，比如dc:title和dcterms:alternative，通过http://purl.org/dc/elements/1.1/和http://purl.org/dc/terms/，可以找到title与alternative的定义，并获知这两个词汇间的关系。这种关系并不是通过数据格式或编码表现出来的，所以我说它们是隐含的。（我之所以强调不是隐含表达，因为“显式地、外在地表达”是元数据语义编码的一个重要原则，在具体应用中，必须通过QName、XML/S或RDF/S等各种手段，显式地表达语义关系，否则就可以认为这种关系不存在。DCMI近年来在编码规范讨论过程中所做的一系列改变，很大程度上是为了这一点。）

针对“我不同意你的看法，如我前面“摘要”中3、4、5所言，这样做正是为了更清晰地表达关系，而且，内容结构与数据文档保持各自的独立性，对于数据的生命周期管理，如对于XML内容结构修改变化的版本管理，有极大的好处。即：可以用不同的Schema读相同的数据，而不需要数据作任何更改”

我的看法：可能是因为我的“隐含”说法让你误认为我不重视数据以外的XMLS这个内容结构定义文件。事实上恰恰相反，我更关注这个XMLS。有时，为了表述元数据元素间的关系，在言语的贫乏下，XMLS语法就成为我的救兵。对于你“内容结构与数据文档保持各自的独立性，对于数据的生命周期管理，如对于XML内容结构修改变化的版本管理，有极大的好处。即：可以用不同的Schema读相同的数据，而不需要数据作任何更改”的表述，我想补充一点理解——结构定义与数据文档确实是相互独立的，但它们是相辅相成的。关于它们间的关系，似乎容易引起类似先有鸡还是先有蛋的争论。而我认为没有规矩不成方圆，事实确定一个结构定义，以此规范相应的数据文档更宜。因而，我认为一个规范的元数据体系，其数据结构的定义就不应该有摇摆性，所谓用不同的Schema读相同的数据，而不需要数据作任何更改的“好处”无从谈起——因为只要不同的Schema定义的数据，即使看起来相同，也应该看作不同的数据（你如何确定其中可选的数据差别呢？）——这点类似你评论谢涛的“一个修饰词只能修饰一个元素，即使它们形态上一样，也必须认为是不一样的”。再从语义打个比方，同是title，对于人事管理体系来看，它可能指的是头衔，而对于图书馆体系来看，它可能指的是题名。

实际应用中，对于资源的描述内容，即数据文档可能有不同，但应该且必须受同一个Schema文档的规范和约束——我的这个表述，可能与你“可以用不同的Schema读相同的数据，而不需要数据作任何更改”的表述刚好相反。用不同的Schema读相同的数据，正是我认为导致DC应用混乱无序的最大症结。林林总总的数据样例，居然无法用同一种Schema来定义或表述其结构。不同人的眼中有不同的哈姆雷特——DC应用中的这种摇摆性，看起来讨好了不同的观点，将只要标榜自己是DC的应用都纳入自己的阵营，貌似强大和影响广泛，但这种阵营总是不堪一击的。于是，采用无歧义的简单DC，就被垢病为不足以详细描述资源；采用随意且不经约束的限定性扩展，就被垢病为跟扩展MARC字段有什么两样？先进性何在？联想起“一个中国，各自表述”，看起来相安无事，但统一遥遥无期。如同谢涛所说，不管什么样的数据，计算机都可以处理。但有某种规范和唯一性，才有数据交换互操作性——即使这种规范和唯一性有些不合理，为了保证数据交换，我们首先得认同它。当然，如果理由充分，完全可以用更合理的规范和唯一性来取代旧的规范和唯一性。或许这也是我特别希望在行业应用尚未起步或大规模起步时，能通过交流或辩争，提前形成一个更合理更规范的数据结构定义，从而防范日后的积重难返——简单的比方，LCMARC定义之初，由于没有意识到计算机的强大，在字段内容中添加了ISBD分隔符。数据的积累，导致取消分隔符或兼容它的成本过高，然不取消它则著录成本也不菲。

(可能我的表述不太准确，让你有所误解。1、不同XMLS读取相同的数据是可能的，这里面不存在1:1原则。举例来说，用dcterms.xsd来处理dc.xsd的数据，理论上毫无问题。DCMI建立抽象模型的一个目的，就是不同的编码达成语义上的一致。2、不同XMLS共享复用，当然其中要处理兼容性、以及dumb-down问题。这可以由XSLT作映射来动态解决。不论哪种方法，实际上都能解决格式/模式与数据的独立性问题。你说的歧义，多不是由模式造成的，而是由元素定义–包括Domain/Range的定义–的模糊性和元素之间关系的不确定不兼容造成）

那么，现在我试着分析一下当前DCMI提供的Qualified DC XML Schemas（http://dublincore.org/schemas/xmls/）：

先在dc.xsd中，定义了一个SimpleLiteral数据类型：

即不允许下面有子元素，可以带一个xml:lang属性。
再定义了一个抽象元素any，并赋予它SimpleLiteral数据类型：

any是抽象元素，在数据实例中是不允许出现的，所以它仅是一个占位符，目的是方便后续的元素定义。
15个DC元素通过置换组定义，实现对any元素的替代，因而自然就继承any元素的数据类型：

再在dcterms.xsd，通过导入dc.xsd，从而可以引用dc.xsd中的定义：

然后再通过置换组，实现限定词对相关DC元素的替代，因而也自然继承了相关DC元素的数据类型：

可以看出，DCMI提供的Schema如此定义，自然如下数据实例就是合法且有效的：
xmlns:dc=”http://purl.org/dc/elements/1.1/”
xmlns:dcterms=”http://purl.org/dc/terms/”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=”http://example.org/appqualifieddc/ appqualifieddc.xsd”>

TITLE

ALTERNATIVE

SUBJECT

这也是我们在开发过程中，在没有得到官方支持或行业应用支持的时候，首先需要兼容或输出的数据样例——至于系统内部如何采用更合理更有技巧性的存贮格式，就是八仙过海各显神通了。

然而：

等价于：

所以，刘所认为通过Schema文件能看出平面数据的立体结构，以及看出显式表达出元素与其限定词间的关系是不太成立的。

（根据目前DCMI给出的xsd，你的上述说法是有道理的、正确的。我的说法的依据不是Schema文档，而是根据DCMI的“原则”，当然这些原则没有见诸文字是不可靠的。我以前根本没有仔细去看这些给机器用的文档，惭愧一个！值得注意的是目前的dc.xsd和dcterms.xsd看起来是不支持DCAM的，因为所有的属性都是作为Literal的，而不是resource。目前在DCAM中必须支持作为资源的属性和属性值的编码，也就是说这两个文档是我在深圳发言的PPT中所说的DCMI1.0，而不是2.0。因此在此提醒两位大侠，编码的模式可能于近期会修改。

说起上下位关系在XML模式中的编码，目前这样做是平面还是立体，因为substitutionGroup并不限定语义，是不是可以交给应用系统去实现上下位关系呢？因为如果没有这种上下位关系，在语义上是不符合DC元数据原义的，子元素不可以随便从属于多于一个元素，并且无法实现Dumb-down。）

上述两种Schema定义方式，都只能得出如下数据格式：
TITLE
ALTERNATIVE
即数据中dc:title与dcterms:alternative是平级的或平面的，在Schema中定义，它们也是平级或平面的。
至于认为采用substitutionGroup=”dc:title”而不采用substitutionGroup=”dc:any”，就可以看出alternative对title的继承或置换关系，仍只是一种从字面上理解而非技术上理解的思维。

我们再来看看假如alternative在具体应用中，还不足以深入揭示title细节，假如DCMI用更细的parallel、cover等表达并列题名、封面题名时，就得修改DCMI提供的Schema（注意，为了节省阐述篇幅，我没有用扩展的Schema来定义这些可能扩展的限定词，而是假设DCMI扩展。它们道理相同）：
即删除

增加：

同志们，可怕的事情来了！因为新的Schema文件，将无法验证旧数据了。当然，把旧数据按这个修订规则作一下数据转换、重构一下检索点也是能解决问题的。

(如果两个XML模式如上所说，需要达到互操作，可以有两个方法：1.无损的方法：一个大的包含所有元素及其约束的schema；2.有损的方法：都转换成一个中间的、用于互操作的schema。无论哪一种方法，模式与数据都是同等重要的，而且原始的、能够完整解析数据的XML模式无疑对于数据来说是最重要的。数据间的互操作，首先是在模式上做的。)

再看看我推崇的数据格式及其Schema：
先修改dc.xsd中的SimpleLiteral数据类型定义：

即增加一个可选的refinement属性，这个属性可选，其值为任意字符串。注意，这个属性也可以通过应用自定义的Schema定义，并在dc.xsd中导入这个扩展Schema即可实现属性引用。

那么，既然我们定义了一个值为任意字符串的refinement属性，就可以根据应用需求，存贮五花八门的限定词，而不需要再定义什么：

对于如下的数据，修改后的Schema都可以实现验证和约束（即我所谓同一个Schema约束多个数据实例）：
TITLE
ALTERNATIVE
PARALLEL
COVER
其中，refinement值可以不用QName，采用QName仅是为了照顾语义:-)

（你当然可以这样编码，在实践中也确实有各种各样的自定义方式，相比较而言，您这种可能还算是比较客气的，至少refinement可以看成是XMLS的保留字。然而由于DCMI的初衷就是对于元数据——包括资源的类型词表、元素、两类修饰词、甚至取值的规范，都进行规范，当然Literal是在规范之外的，你这样扩展的元素，只能属于DCMI能够关照的领地之外的了）

再看看表达同样语义的，DCMI推荐的数据样例与我推崇的数据样例的信息寻址优劣：
DCMI数据样例：
DATE
CREATED
VALID
AVAILABLE
ISSUED
MODIFIED

采用XPath对没限定词的日期寻址：
日期=”/dc:~~title~~date”
采用XPath对带限定词的日期寻址:
创建日期=”/dcterms:created”
采用XPath对带限定词的日期概括寻址:
其它日期=”/dcterms:created”+”/dcterms:valid”+”/dcterms:available”+”/issued”+”/dcterms:modified” //如果有更多限定词，需要修改寻址方式以实现穷举
采用XPath对所有日期概括寻址:
所有日期=”/dc:~~title~~date”+”/dcterms:created”+”/dcterms:valid”+”/dcterms:available”+”/issued”+”/dcterms:modified” //如果有更多限定词，也需要修改寻址方式以实现穷举

我推崇的数据样例：
DATE
CREATED
VALID
AVAILABLE
ISSUED
MODIFIED

采用XPath对没限定词的日期寻址：
日期=”/dc:~~title~~date[not(@refinement)]” //不带refinement属性的即为无限定词的日期
采用XPath对带限定词的日期寻址:
创建日期=”/dc:~~title~~date[@refinement='dcterms:created']” //refinement属性值等于dcterms:created的即为创建日期
采用XPath对带限定词的日期概括寻址:
其它日期=”/dc:~~title~~date[boolean(@refinement)]” //凡带refinement属性的即为日期的限定词，包括dcterms:created，dcterms:created，dcterms:valid，dcterms:available，dcterms:issued，dcterms:modified
采用XPath对所有日期概括寻址:
所有日期=”/dc:~~title~~date” //忽略refinement属性，包括dc:date，dcterms:created，dcterms:created，dcterms:valid，dcterms:available，dcterms:issued，dcterms:modified

前后对比，难道还看不出后一种除了在编码结构（注意，不是数据内容）上多些冗余，但在显式体现DC元素及其限定词间关系、表达“向下兼容”、以及系统寻址稳定性上，体现出强大的优势吗？（采用XPath属于应用层面的解决方案，从元数据规范层面来看，属于应该尽可能避免的权宜之计。）

谢涛老师留言：

1)

keven老师所说“因此DC元数据的XML表达（包括RDF表达）从数据上看起来是平面的，但是其结构和语义是用XMLS来约束的（如果是RDF，扩展的元素用RDF Schema进行定义），因此不能认为它是平面的。”我觉得部分可以认同。

我的理由是，XMLS表达了额外的意思，信息比单纯的数据记录来得丰富。例如keven老师所举的，从Schema中能看出一些蛛丝马迹，让人觉得element和修饰词之间是有“概念层级关系”的。

但是我觉得这些还不够，不是语义信息的全部。仍需要外在的人为的规则来帮助约束。

（编码规范应该“约束”到什么程度？一方面取决于描述模型应该“抽象”到什么程度，是否能够达成共识；另一方面又受限于形式化语言描述能力。当然，可以说XML作为一种元语言的表达能力是无限的，这就需要在复杂性与简单性、能力与需求之间建立一种平衡。上帝的归上帝，凯撒的归凯撒。标准规范所矛盾的地方，也就是在于划定一个界限。）

2)

在谈到语义层级结构的时候，需要注意语义上的层级并不对应数据实例中的结构层级。

比方说，alternative在概念上是title的下位概念，但是并不意味着在编码阶段要在alternative元素外面括一个title元素。

我举一个例子就可以说明问题：人类是从鱼儿进化过来的。一个胎儿在子宫中就模拟经历了全部的进化程序，但出生的时候，已经是一个人，而不是鱼儿。因此对应的说，从概念上alternative和title有“XXX化”的关系，但是在编码的时候，已经“出生”，语义和概念的演绎过程已经结束。也正好比端上餐桌来的菜，许多已经看不出原料。

所以我们眼睛看着一个DC element或者修饰词的编码实体，脑子里面可以想象它们的一切有关语义的事情，但不一定要追求“编码形式上的直白体现”。

但是编码层面也不是不能允许有特别的“结构”。我能想到的例子，就是同一个title，因为语种不同，不同的表现实例之间，它们实际上有紧密的联系 – 就是它们实际上都是用来描述一个东西的。好比孩子有大名和小名，看见两个名字并不是说有两个孩子，而是指同一个人。那么这时可以用一个类似这样的XML元素作为容器把它们包装起来。这样的设施在类似RDF这样的“发育良好”的框架下能够得到很好的表现。如果纯XML编码(非RDF等现有框架)要吸取这种特点，我不反对。

总之我暂时反对在编码层用某种结构表达江汇泉所举例的那些语义信息，而不反对用来表达其他的信息。

这里也顺便提到RDF和纯XML编码的关系：RDF看起来是XML，但是某种意义它已然不是XML。就好比豆子酿的酱油，酱油已然不是豆子。豆子不过是其原料。因此纯XML的原始性和自由性，像一片未开垦的处女地，容易让人迷惑，无所适从。（精彩的比喻！）

但是从时间和实践的发展看，使用纯XML的趋势是有的。可以理解为人们对RDF等实践后带着更多经验对纯/简单XML格式的一种回归。或者说一种“简约风潮”。

3)

我觉得DC的编码格式要少，要精。我们有理由扩展各种编码格式，但是理由要充分。

虽然随便定一个Schema就诞生了一个新格式，但是软件区读取这样一种新格式，是需要代价的，是需要编写代码的。

有人说通过XSLT可以在这些格式之间转换。但，没问题转换什么呢？本来如果不需要那么多格式，就不要先去造出来然后转换，这事情并不好玩。

目前的DC推荐的Schema，只是定义了非常非常局部的编码形态，它本身是允许这些局部和其他未定的XML文档结构糅合使用的。这种无为，也就是说不去定义全文档结构，也许就是一种好的办法，至少局部方面我们有一定的规矩。

只要一个具体项目用了dc或者dcterms的名字空间，就意味着认同这种简单的局部结构。这就不能随意了。所谓“可以自行扩展”，其实说的是XML文档的其他部分。比方说这些DC element物件的容器部分，根元素，DC是不做规定的。

所以从字面说，认为DC编码形态可以自行定义，那是一个误会，或者一个不精确的说法。其中的局部是已经定义死了的。

当然DC所推荐的编码方式也在发展。我们可以视为不同的版本。只要是同一个版本，那就是“死”的。

在编码方式有必要变化和扩充以前，肯定需要一个相对较长的稳定期，这对一个具体的项目很重要。

如果和ISO2709相比较，ISO2709的编码格式已经确定，在语义层面，字段名是留有扩充空间的。而XML格式的DC数据，一个是编码格式有不确定性，另外语义层面也有很大的扩充空间。尤其是前者给开发人员出了很大的难题 — 也可以说机遇与挑战并存。

希望在某些限定条件下，大家用的编码形式趋于一致，或在在少量的可选项中选择。否则数据可交换性就成了一个大问题。

当然这里的“可交换性”笼统说也不好。具体数据实例中，DC规定的那15元素的交换性还是不错的，如果都用DC推荐的编码方式的话。其他各系统自行扩充的部分，交换性如果不好，何以能怪到DCMI呢？这部分是“附带生发的情愫”，想想就明白了。

从XML技术细节的角度，在一个XML文档中，DC已经规定的那些element的编码对象，其位置层级的(潜在的)变化多端，并不构成对开发的难题。假如我们用XPATH寻找这样的对象，用一个“//dc:title”就能全文档寻找。

如果一个实际系统把这些编码对象进行了层级管理，但是另一得到这些数据的系统并不“以为然”，把这些对象理解为平坦结构，那么这“最低一层”的语义交换还是可靠的。前一系统关于层级关系的信息，属于“多余的表情”，被后一系统忽视了。这也是一个“好”的例子：毕竟该能交换的东西实现了能交换。

4)

keven老师所说“我不同意你的看法，如我前面“摘要”中3、4、5所言，这样做正是为了更清晰地表达关系，而且，内容结构与数据文档保持各自的独立性，对于数据的生命周期管理，如对于XML内容结构修改变化的版本管理，有极大的好处。即：可以用不同的Schema读相同的数据，而不需要数据作任何更改”我很赞同。

这是一个原则，对很多系统都适用。

江汇泉说“因而，我认为一个规范的元数据体系，其数据结构的定义就不应该有摇摆性，…”

我认为数据结构一旦定义，自然就是没有摇摆性的。比方说DC决定仅仅干预文档中的“DC能够管辖的部分”，这个原则就是没有摇摆性的。但是它是否对应用人员的心理带来摇摆的感觉，这可不一定。

正因为DC约束了自己的干预程度，其实总体来看DC彻头彻尾就是一个摇摆的定义，在编码结构上。它留出了空间给具体的系统，它绝对不去干预那些领域。这自然都带来了总体的摇摆性。

(这其实是DCMI提出元数据应用纲要(DCAP)的初衷：只关心它所能且该关心的，给别人也留口饭吃。网络世界观认为，大千世界，民主自由，异构是无限的。

但是，DC对于自己的领地，自认为一直立场坚定的，只不过认识有一个过程。DC立志成为语义Web(SW)的基本语义，SW尽管不同层级的表达能力不同，但唯一共同的基础是建立了整个因特网的相等关系：即基于命名域构成的URI而达成的同一性判断。其它的数学和逻辑基础，简单的已经建立（如包含，甚至否定），而大多（如相似、相近、甚至“相关”–概念间的距离等）则还在争论不休)

而且我们限定话题，针对“DC能定义、该定义”的那部分而言，也有一定语义层面的模糊性和可扩充性，说成摇摆性也行。

就如同我举例说明的，“OCLC”的全写是什么？可以有好几个附会的版本出现。类似的情况也发生在格式定义中。最低限度，是格式将来发展时打补丁的需要，我们没有必要歧视这种属性。

具体编码数据中关于语义和其他的线索信息很少，它于是自然允许后面的Schema等等一切设施作出某种新的“附会”和改进。编码数据中的字面信息(例如名称本身)是很明显的，这部分信息当然不能随便动。但是“后台”信息不在数据体里面。我认为这是自然的，有好处。

不同的系统甚至可以对语义作出自己别致的解释。但是也别对这一条太敏感。其实(元素)字面意义已经限定死了，能自由的空间是小空间。元数据集框架的巨大影响还在。这是说语义，而不是结构和形态。

5)

江汇泉举例试图说明XPATH下穷举不同的修饰词多么麻烦，而用冗余的元素名则可以避免这个麻烦。

以我的经验来看，创建那个穷举修饰词列表的事情，可以是软件完成的，而不是要人来次次“手书”。比方说具体系统有一个配置文件，软件写好一个循环程序，随着配置文件的些微变动(这变动当然可以由人进行)，循环自然能穷举当时该穷举的对象。这是“不费力”的。

也好比我们实际运行的系统中，SQL语句中的where子句都很复杂，但正是由程序中的循环过程来创建的，对人来说并不复杂。– 让机器对机器复杂去吧。

这一点小case，得不出“强大优势”的结论。

凡是都要算代价。精于算计不是什么坏事。我要和江汇泉算另外一笔帐：如果所用的编码格式中，XML元素名(对应于DC元素名)和 refinement属性的对应关系发生了变化，谁来负责修改数据本身？是江汇泉自己一一调出来数据修改几年呢，还是由一个批处理程序来修改？我们知道，一个具体系统，所用的元素集肯定在不断调整之中，语义和结构都可能调整。

而且所增加的冗余信息，完全是冗余的，是可以割除的阑尾。

宏大论述了语义和结构的关系，但是这个突发奇想的编码格式，我觉得和刚刚的宏大论述关系不大，成了“话锋一转”，突然谈论另一件不相干的事情了。

近期关于元数据编码的讨论

keven — Thu, 29 Nov 2007 08:12:55 +0000

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

承蒙谢涛和江汇泉两位技术大拿与远洋老师在我的博客上发起了热烈的讨论，所涉及的问题实在是在实践中非常重要，却很难武断地进行“推荐”。这里只能就我对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文件的根元素指向格式解析模式中（通常是一个形式化的元数据应用纲要），可以明确它们的上下位关系，通常在如下的文件中规定格式：

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

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

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

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

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

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

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

江老师留言1：

1、如我在“DC元素的中文翻译”曾有的“喜”、“忧”感慨。“DC元数据元素集国标项目”如果仍停留在DC元数据的最基本的15个元素语义，甚至纠缠在是否将DC元素名称翻译成汉语上，就真如同你所谓的“如果翻译了，就不是DC了（“盗版DC”？）”。对于具有高度民族自尊心的同胞们来讲，不要英文，要汉字的心情可以理解。几千年形成的汉字，丰富的语义和字形是我们的骄傲（玩话中有话和文字游戏，岂是那帮洋夷比得了得？），但对于直肠子的计算机来讲，可不如英文来得直接。并且，既是国家项目，也得上纲上线——港澳台同属中华大家族，这个DC元素名的中文翻译，是采用简体汉字还是繁体汉字？偏重一方都显得厚此薄彼，弄成简繁两套国标显然又是一种浪费。
3、概念的推敲与翻译，用许三多同志的话来质询，就是这种形为是否有意义。远洋的问题：“元素修饰词不知道是哪个英文词？Qualifier还是 refinement? 不过不论是哪个，都不应该是sub-element （子元素），对吗？”——我的理解是，Qualifier还是refinement类似“下岗”和“失业”，词不一样，但我们理解到它们的意思一样就行了。在标准中确定一个，意义虽不大，但总可以省些交流的麻烦。但如果弄成sub-element （子元素），可能就有点引入歧途了。因为，元素是元素，子元素也是元素，但DC为什么有元素与限定词两个体系呢？显然不是没有原因的。我的理解是，DC元素是用来描述资源的，而限定词是用来描述（限定）DC元素的，描述对象都不一样，sub-element概念除了误导外还有什么价值呢？（我同意不要误导之说，的确，把它认作独立的元素，然后与其它元素建立起上下位关系即可，本来就是一种让机器读懂的规定）

始终在想，为什么这么几个国字号的项目，总在语义层面中纠缠（元数据的目的就是要表达语义哦，以前表达不了，还不让现在表达啊？），就不能直白告诉我们如何在计算机中兑现和确定一个数据交换格式呢？（要知道所有计算机科学的进展，都是人和机器不断靠近的过程）作为系统开发商的我们，等得花儿都谢了（等待是值得的，机遇总是交给有准备的人）。如果我等草根阶层，在没有官方的指导下，弄些自定义的数据格式，又担心才思浅薄，误导我们的用户，更被日后官方格式制订者耻笑。所以，今天借刘所的宝地，提出几个问题，希望见多识广的朋友们能告诉我某些具体应用中的数据格式或处理方式，先谢过了：
1、请问DC应用中，如何处理汉语拼音？我得理解是应视汉语拼音为描述内容的规范体系或编码方案，采用类似：san guo yan yi的编码格式。请朋友们告诉我，是否在某个具体应用中看到过汉语拼音的编码格式，其数据样例是什么样的呢？（这个今年的DC会议上，日本人Akira Miyazawa专门发表研究了对这个问题的研究心得，讨论时Tom还是Mikeal说起，W3C也有人研究，我仔细考察过，再给你意见）

2、简单DC数据的XML编码，基本上没有异议。但对于限定性DC，就没看到有多少具体应用。但实际应用中，简单DC是不足以承担具体应用需要的更复杂的描述需求。那么，请问各位朋友，能否提供些具体应用中产生的限定性DC数据的XML编码样例？（这与目前成熟的计算机软件系统体系架构有关，具体的应用都要采用成熟的技术，因此直接用XML编码的应用很少，DC大多作为一种交换格式，于是编码的一致性就显得不是那么重要的，谁都可以自定义，等DCMI推出推荐意见之后，再on the fly修改）

3、DC官方网站中的“Guidelines for implementing Dublin Core in XML”，Recommendation 6. Element refinements should be treated in the same way as other properties. The name of the XML element should be an XML qualified name (QName) which associates the element refinement name with the appropriate DCMI namespace name. For example: 2002-06

推荐 DC元素与元素限定词都编码为XML元素，采用QName，通过所引用的namespace来隐含表达元素与限定词间的关系（正如后面谢涛所说，这样倒反而不是“隐含”，而是通过XMLS显式地定义。当然，只是说法而已）。对于这点我有异议，采用 XML编码是DC元数据的一种进步，因为XML是一种高度结构化的编码方案，通过XML结构，可以在数据内部清晰表达出元素与限定词间的关系，为什么非要采用外部的隐含表达呢？“言之不足，手之舞之，足之蹈之”——辅助手段是在主要手段不足时用，为什么非要舍本逐末呢？（我不同意你的看法，如我前面“摘要”中3、4、5所言，这样做正是为了更清晰地表达关系，而且，内容结构与数据文档保持各自的独立性，对于数据的生命周期管理，如对于XML内容结构修改变化的版本管理，有极大的好处。即：可以用不同的Schema读相同的数据，而不需要数据作任何更改）

我对如下限定性DC编码方案情有独钟：
2002-06
它的优势除了在于从结构化上清楚表达了元素及其限定词关系，更是忠实遵循了DC向下兼容原则——具体应用中，随便你扩充或忽略限定词，数据结构稳定、信息价值不会丢失。而推荐格式，除了少些数据冗余（这种数据冗余是结构上的而非信息内容上的，所以计算机处理时完全可以忽略不计），我看不出有别的优点。—— 当然，从语法转换来讲，这两种格式是等价的，但从对DC的理解来看，推荐格式显得比较矛盾。简单来讲，既DC明确了元素限定词不是元素（语义重叠的不能扩展为元素）(这里又是一个老问题：即元数据的元素与XML的元素不是一回事，元数据的元素和子元素都可以用作XML的元素)，那么，从形式来讲，用XML元素体现DC元素，再用XML属性体现出限定词（也就造成元数据的子元素不必表现为XML的限定词），这才有主次和差别之分嘛。何况，同为DC限定体系的编码规范体系限定（encoding-scheme），推荐又采用XML属性xsi:type来表示，岂非厚此薄彼不统一？参考推荐格式（这里实在需要强调一下：元数据的语义模型与编码可以而且应该分开，一样的模型可以用不同的编码，DC编码体系修饰词是对属性值的说明，当然可以用xsi:type来说明，非常自然，不必与其它修饰词统一编码方式）：
http://www.ukoln.ac.uk/

事实上，在2002/09/09发布的“Guidelines for implementing Dublin Core in XML”版本中，有以下的表述：
Recommendation 6. Element refinements should be treated in the same way as other properties. The name of the XML element should be an XML qualified name (QName) which associates the element refinement name with the appropriate DCMI namespace name. For example, use

2002-06
rather than
2002-06

但在2002/12/02以后的版本中，认为2002-06优于2002-06的表述就被取消了。只不过推荐以下格式：
foo

foo

明眼人都看得出，上述两种方式确实既冗余，又没“意义”。

我特别好奇，想了解一下作者对这个表述的修订本意是什么？然E文水平有限，担心对方听不懂——还望刘所或与我同样好奇的朋友替我与作者交流一二，并将结果转告与我——再次谢谢了。(一直没有研读DCMI最近正在草拟的更新版推荐)

最近，公司在开发DC编辑系统的“等米下锅”（寻求一种官方的、广泛应用的数据格式）过程中，为了降低开发成本，争取兼容常见DC数据格式过程中，有些慎重而严肃的争论和决策犹豫。因而对多年停滞不前，没实质进展的权威机构“不作为”行为更感郁闷，牢骚一多，就在刘所宝地吐了一地，还望见谅。希望此处的高朋能可怜我郁闷的心情，帮帮我，帮我找找实际应用中的限定性DC数据样例，多多益善——对于朋友的帮助，我们将回馈一个优秀的DC编辑系统供其本人使用。

江老师留言2：

仅从DC原则来理解——DC的原则是其立身之本，如果这个原则都有动荡性，体系也就不稳定了——我是支持远洋“元素修饰词不知道是哪个英文词？Qualifier还是refinement? 不过不论是哪个，都不应该是sub-element （子元素）”的说法。

简单分析，当前alternative作为title的限定词，显然语义限定还比较宽泛。当某日，需要把这个title的限定词更加细化，那么后出现的限定词难道应该成为sub-sub-element？这种理念下，编码是不易体现的——不可能在XML中同时出现title,alternative 与XXX等结构吧？如果出现了，如何体现XXX是title的限定词而非是alternative的限定词呢？

远望师“在DC中的refinements本身还不是一般有等级的那种sub-elements”的概念，是否意味着我钟情的类似编码有了更有力的支持？编码类似如下：
正题名
交替题名
从编码结构来看，正题名与交替题名是平级的——等级或从属是通过属性值来体现的。将限定词作为属性值，可以应对不同的需求扩展，更可以忽略这些限定属性，仍体现出大概念描述，这即所谓的向下兼容。

远洋师也是见多识广，能否帮我寻找更多的数据应用实例供参考。我们的本意是寻找一个更合理、更官方（更权威）的数据格式作为我们首先要对付或支持的格式。当然，如果没有这些数据，只得自行确定。但确定时，能有更多专家指导，总比我们闭门造车，孤陋寡闻弄些贻笑大方的数据格式好些。（找一些实践的数据格式可能很容易，但作用并不一定如您所想得那么大。具体的实例永远都是片面的，同样的XML经过输入输出也会面目全非，谁的责任呢？现在OCLC自己还没有“最佳实践”，怎会有“最准确的数据” 。当然，我们不能因此不去努力）

谢老师留言1：

在博客上短短数语发表意见，可能前后的语境不见得清楚，不过我还是尽量讲清楚。

DC在两个方面耐人思量：一个是语义方面。比方说alternative和title之间确实有不同寻常的关系。另外一个是编码、物理结构方面。比方说现在DCMI推荐的编码的guidline，把alternative和title并置，从形态上看起来是差不多的平起平坐的东西（没错，正是！）。

从软件实现的路径来看，首先是形态上的理解和兼容，能够存储数据，能够直白地检索（软件实现人员一般都这样考虑，而标准制定则不这样，考虑更多的是系统架构方面的问题。首先架构分层，语义与结构分离，表现与存储无关）。

所谓直白地检索，就是说你要我检索title，我就检索出title，你要我检索出alternative，我就检索出alternative，软件表现比较傻，比较单纯。

软件处理上然后下一个层次就是能够理解和处理语义关系。比方说在某种情况下，软件需要理解到alternative就是title的一种，能够扩检和缩检。所谓扩检，就是我笼统要title，软件能把alternative也算在内给我检索出来；所谓缩减，就是我看到广义的title检索命中结果很多，我希望缩小一点范围，专看精确属于alternative的那些。（软件难道不能通过Schema做到这一点吗？）

依我的经验，DCMI推荐的所谓元素和修饰词并置的编码方式，并不影响软件实现上述的第二层次。因为数据中，title和alternative在数据记录中没有明示的关系，在DC规则体系中，有暗含的信息表示。所谓“暗含”，是对于数据而言，因为数据没有明示，所以叫暗含。而对于DC的规则体系，是明确说了title和alternative两个概念之间的语义关系，这并不是“暗含”，而是明示。(关于这一点，前面已经说了)

对于DC数据的软件利用和处理，数据本身含有的信息和规则体系含有的信息都要参与作用。设想只通过数据就获得全部信息，是不可能的，也是没有必要的。（正是Schema与XML文档之间的关系）

江汇泉同志(请原谅我在这里使用他的真名，因为学术讨论似乎没有必要通过网名)偏爱类似

交替题名

这样的编码方式来表达修饰词，我想原因大抵是里面很有一些“附加”的信息，他认为这样对软件好，具体来说就是对于实现上述第二层次的软件功能有帮助。根据我的经验，这没有必要，软件本身不需要通过数据体内的某种信息来搞清语义，可以通过外在的信息来搞清(比方说含有某种规则的配置文件)。这种“好意”，实际上带来了数据的冗余，某种程度会增加软件的麻烦。

当然，我不反对在软件用户界面上，以某种形式揭示、体型用户关于title和alternative的语义关系，帮助用户录入数据和操作软件。但是这个任务不该和编码层次挂上钩，毕竟用户一般情况没有必要看到赤裸的XML数据。

实际上，我也是最近因为软件开发的缘故，看到DCMI推荐的平坦编码形态，才促使我思考关于修饰词到底是形容词还是名词这个比较深层次的问题。

从DCMI目前提供的dcterms语义、形态定义看，类似alternative这样的修饰词在语义类属上，只能属于一个element，而从未发现有从属于二个或者以上element的例子。我这个感觉如果有误，请指正。（一点没错，一个修饰词只能修饰一个元素，即使它们形态上一样，也必须认为是不一样的，必须给出不同的命名域。在DCMI的描述模型中，元素的domain和range决定了资源的属性不应该重叠交叉，因而子元素–姑且这样叫–不可能在一个方案里复用）

从我看到的这个现象，侧面证明了所谓修饰词的“名词”属性。也就是说，在讨论中，大家摆开了揉碎了说，可能alternative是一个类形容词的概念，可以和许多名词组合起来使用，但是在编码层面，任何落地了，也就是出现在类似XML文件中的物体，都是“名词化”了的概念。好比孩子出生后，就是一个自在的生命，但是要在中国生活，你得给他/她上户口，对不对？

从编码层面，目前的DC体系中，一旦落实到物理上的层次，都是名词。也就是说，如果一个形容词找不到和它结合的名字，就不能落地，就不能参与编码。

在DC体系中，这个“参与化学反应”的名词很显然：基本就是那个element概念。比方说，alternative要落地，它拉上它的语义关连对象title就可以了。这个规则是如此直白、简单，人和软件都会觉得它很漂亮。

如果我们强烈设想，alternative是一个形容词，我们甚至在编码阶段也要体现这个意图，让它明明白白和element例如title组合起来用，在编码阶段才组合，那么这恐怕不是现在的DC体系，而是一个大家设想的更好的元数据体系。所以我提醒大家不要把对DC未来的改进设想和对目前做法的阐释混淆起来。

如果alternative在编码层面真的是一个形容词，只需要一个证据就够了：你告诉我，alternative可以和两个不同的元素名结合使用。但是据我所知，没有这样的证据。

我之所以说江汇泉推崇的编码方式，元素名在里面是冗余，那时因为，在现在的DC体系中，alternative是title的修饰词，那是一句废话，是体系结构自含的，既然是废话就不要在编码中体现。

而如果确实DC原意是要把alternative当作形容词，alternative确实可以和不同的元素名组合使用，显现出千变万化的效果，那江汇泉推荐的编码方式就是显然和直白的了，毋庸置疑。但是我觉得这是一个误会，等于江汇泉编码出了一个设想中的可能未来的DC，和现在的DC不是一个东西，若加给现在这一代软件用，反而带来了无穷的烦恼。具体来说，就是这种编码方式所优势的“千变万化”的组合效果，正好是目前DC禁止的 — 一个修饰词能能老老实实属于一个元素，和一个元素进行语义组合，而不能和多个元素进行语义组合。(以上关于名词或形容词的探讨在我看来基本上没有必要，因为元数据只是机器语言，作为元素名称，都名词化了，不存在形容词的可能，修饰关系只是人强加给他们的)

我相信当然可能有其他元素有需要alternative的潜在需求。但是在目前DC框架下，人们只能寻找一个不同的词(哪怕意思本来就相似)，设定一个完全独立的URI，给那处需要的地方使用。（正是我上面说的道理）

如果因此认为DC这样的语义表达方式笨拙，那也没有办法。不过至少，这种“初等”的表达方式，是目前软件开发技术所习惯的，虽然不高明，但是还可以用。（我倒认为这正是DCMI的高明和精彩之处）

这个讨论真不知如何进行下去了，这边的帖子还没有改定，那边的留言又来了。下面是谢老师留言2：

说一个XML文档需要有XMLS来规范，我想这一点江汇泉体会应当很深(也有过不少实践)。（自底向上的考虑永远有无穷的复杂性，而自顶向下地抽象出描述模型往往能够豁然开朗）

好比我们在讨论C语言的编程，黑板上写写画画，大家很开心，但是一旦敲入计算机，用某个编译器进行编译，就会发现软件会理出一些错误和警告信息，回头来再检验自己的理解，发现计算机真是很“轴”，偏差一点都不行，必须得那样，不过也同时带来一些更别样的思考，对所谓“语言”的理解会更深。(编程语言永远是人适应机器吗？)

一个XML文档的编码规则要“落地”，最终还是需要落实到XMLS的编制、检验、测试上。有时候会发现本来说得好好的，但是一定义Schema时就暴露出一些含糊之处，或者Schema体系本身不允许的“超人”结构，那么这时候原来的意图就必须和现实的局限进行妥协。

一来二去，最终会订出一个人和计算机都比较满意的“实践最佳格式”。

有没有实在定义不出一个具体XMLS的XML文档格式呢? 当然是可能的。这就成为，我说它是怎样，它就是怎样，无严格规则可言，成为人嘴似乎可以说清那个格式，但是无法告诉计算机让计算机自己来精确弄清的浪漫局面。

XML文档基本格式合法，这是一个最低的要求，可以不去定义什么Schema。但是这样的格式一旦交流起来，要大家都去用，缺乏严格的定义，就容易造成创建文档和解释文档两环节的歧义。可以说没有定义Schema的XML文档格式，就是不方便交换和广泛应用的格式。

我们对DC的某种具体XML编码格式的要求，当然是希望它有个具体的Schema来限定最好。DC落地编码当然可以有多种具体的XML格式，但是我们出于交换的需要 — 因为DC生出来的一种重要使命就是用来交换数据的 — 势必希望最好有一种最通用的编码格式出现，大家熟悉它的Schema。这个Schema成为一个“准标准”。

~~~

这个Schema，它因为需要专心描述XML文档的结构，所以它在地位上是很接近“语义”的。但是我觉得它首先仍然是在解决编码的物理结构问题，觉得它非常和“语义”相关，有明显感情上的附会成份。

当然这不是说Schema这一工具对弄清语义没有好处，实际上很有好处。但是我还是宁可认为语义是在讨论桌上、空气中存在的，文章中自然语言论述的一种东西，可以部分附着在Schema上，但成份不是那么浓。

从一个格式的发展来看，有时候老版本的一些误会或者故意预留的空洞，会对后来的修订格式带来意向不到的好处，后来者可以去钻空子、附会、打补丁。这种效果有时候被安排成刻意的。

好比OCLC的缩写到底怎么来的？一开始时Ohio的几个图书馆的联合，后来附会成了Online Catalog，运气真不错。

我这样说的意思，是目前平坦化的DC在XML上的编码方式，其中有不少玄机，留给Schema或者语义专家将来可以玩弄的空间很大。这就是简单带来的某种好处。

数据一旦编制了，就是海量的，其格式难以说变就变。但是可以尽量不变数据，变Schema呀。平坦的格式虽然似乎没有把某些“资源”用穿，那正好也许是下一版格式制定的起点。

实际上从我自己从事软件开发实现的角度，我不太关心语义的精深议论，因为若有什么变化，也不太涉及到具体编码格式的动荡。（要知道你做的就是对于语义的编码，这在计算机过去的所有历史上都是没有的事情，这个事情是从现在才开始的，可能在国内，正是从你正在构想的软件开始的）

ISO2709格式可以装UNIMARC和USMARC，这两个格式在编目人员那里看来水火不容，但是在实现存储的时候，从开发人员眼里看来没什么太大差别。（这个比喻非常恰当和精彩！）

就说CNMARC，国家图书馆和CALIS的著录细节还有很多差异，编目员“明眼人”一看就能敏感觉察，但是从软件大部分角度，这些差异都不是本质的。

就是说我粗略觉得，大家讨论的许多问题可能确实和编码层面无关。因此建议可以先把编码层的实践方向和细节搞清楚，从而就可以开始行动了，具体语义和如何细节著录的事情可以继续吵，但是软件纹丝不动。（这可能吗？那我们就从两端开始吧：你从你的实践开始，我从我的模型开始，我真不知那样的话，我们哪一天才能见面！）

~~~

好了，我想请问大家：DCMI现在有没有这个XML文档编码的Schema？如果有，我想其中的意图可以先打开来领会，而不必盲目讨论了。（不好意思，现在没有。原因一：目前DCAM刚刚搞定，成为DCMI的推荐“标准”，费了老鼻子劲，他们希望这个东东能够超脱一切编码；原因二：DCMI并不关心编码，而把具体的编码交给DCAP，每个具体的应用都可以制定自己的XMLS，当然，最好是RDF/S）

如果浪漫设想了若干格式(变种)，却发现它们通不过这样的XMLS的校验，岂不浪费感情。(一个能够处理XMLS的软件工具，应该能够读入任何XMLS，生成相应的数据结构，动态产生表单和相应的展示界面…可能我的想法过于天真了，开发这样的“自动”工具，的确不是很容易）

这一步“上机实作”，不可省却。希望具体到这一层次进行探讨。