江汇泉老师在我的上一篇帖子中留了一个关于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数据类型：
<xs:complexType name=”SimpleLiteral”>
<xs:complexContent mixed=”true”>
<xs:restriction base=”xs:anyType”>
<xs:sequence>
<xs:any processContents=”lax” minOccurs=”0″ maxOccurs=”0″/>
</xs:sequence>
<xs:attribute ref=”xml:lang” use=”optional”/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
即不允许下面有子元素，可以带一个xml:lang属性。
再定义了一个抽象元素any，并赋予它SimpleLiteral数据类型：
<xs:element name=”any” type=”SimpleLiteral” abstract=”true”/>
any是抽象元素，在数据实例中是不允许出现的，所以它仅是一个占位符，目的是方便后续的元素定义。
15个DC元素通过置换组定义，实现对any元素的替代，因而自然就继承any元素的数据类型：
<xs:element name=”title” substitutionGroup=”any”/>
<xs:element name=”creator” substitutionGroup=”any”/>

再在dcterms.xsd，通过导入dc.xsd，从而可以引用dc.xsd中的定义：
<xs:import namespace=”http://purl.org/dc/elements/1.1/” schemaLocation=”dc.xsd” />
然后再通过置换组，实现限定词对相关DC元素的替代，因而也自然继承了相关DC元素的数据类型：
<xs:element name=”alternative” substitutionGroup=”dc:title” />

可以看出，DCMI提供的Schema如此定义，自然如下数据实例就是合法且有效的：
<my:qualifieddc xmlns:my=”http://example.org/appqualifieddc/”
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”>

<!– Test cases for appqualifieddc.xsd –>
<!– Core Elements –>
<dc:title>TITLE</dc:title>
<!– Refinement Elements –>
<dcterms:alternative>ALTERNATIVE</dcterms:alternative>
<!– Encodings –>
<dc:subject xsi:type=”dcterms:LCSH”>SUBJECT</dc:subject>

</my:qualifieddc>

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

然而：
<xs:element name=”alternative” substitutionGroup=”dc:title” />
等价于：
<xs:element name=”alternative” substitutionGroup=”dc:any” />
所以，刘所认为通过Schema文件能看出平面数据的立体结构，以及看出显式表达出元素与其限定词间的关系是不太成立的。

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

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

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

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

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

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

再看看我推崇的数据格式及其Schema：
先修改dc.xsd中的SimpleLiteral数据类型定义：
<xs:complexType name=”SimpleLiteral”>
<xs:complexContent mixed=”true”>
<xs:restriction base=”xs:anyType”>
<xs:sequence>
<xs:any processContents=”lax” minOccurs=”0″ maxOccurs=”0″/>
</xs:sequence>
<xs:attribute ref=”xml:lang” use=”optional”/>
<xs:attribute ref=”refinement” use=”optional”/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:attribute name=”refinement” type=”xs:string” />

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

那么，既然我们定义了一个值为任意字符串的refinement属性，就可以根据应用需求，存贮五花八门的限定词，而不需要再定义什么：
<xs:element name=”alternative” substitutionGroup=”dc:title” />

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

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

再看看表达同样语义的，DCMI推荐的数据样例与我推崇的数据样例的信息寻址优劣：
DCMI数据样例：
<dc:date>DATE</dc:date>
<dcterms:created>CREATED</dcterms:created>
<dcterms:valid>VALID</dcterms:valid>
<dcterms:available>AVAILABLE</dcterms:available>
<dcterms:issued>ISSUED</dcterms:issued>
<dcterms:modified>MODIFIED</dcterms:modified>

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

我推崇的数据样例：
<dc:date>DATE</dc:date>
<dc:date refinement=”dcterms:created”>CREATED</dc:date>
<dc:date refinement=”dcterms:valid”>VALID</dc:date>
<dc:date refinement=”dcterms:available”>AVAILABLE</dc:date>
<dc:date refinement=”dcterms:issued”>ISSUED</dc:date>
<dc:date refinement=”dcterms:modified”>MODIFIED</dc:date>

采用XPath对没限定词的日期寻址：
日期=”/dc:titledate[not(@refinement)]” //不带refinement属性的即为无限定词的日期
采用XPath对带限定词的日期寻址:
创建日期=”/dc:titledate[@refinement='dcterms:created']” //refinement属性值等于dcterms:created的即为创建日期
采用XPath对带限定词的日期概括寻址:
其它日期=”/dc:titledate[boolean(@refinement)]” //凡带refinement属性的即为日期的限定词，包括dcterms:created，dcterms:created，dcterms:valid，dcterms:available，dcterms:issued，dcterms:modified
采用XPath对所有日期概括寻址:
所有日期=”/dc:titledate” //忽略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属性的对应关系发生了变化，谁来负责修改数据本身？是江汇泉自己一一调出来数据修改几年呢，还是由一个批处理程序来修改？我们知道， 一个具体系统，所用的元素集肯定在不断调整之中，语义和结构都可能调整。

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

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

Last Modified: 星期四, 十二月 6th, 2007 @ 17:50

This entry was posted on 星期一, 十二月 3rd, 2007 at 6:50 上午 and is filed under 专业评论, 元数据, 语义技术. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.