Web上的所有东西，可以看成文本（或数据流），也可以看成是一个个独立的的“资源（resource)”，或者看成这两者的混合（本来就是）。

标 识符是“资源”是否具有独立性的基础，是核心，决定了“资源”的归属、身份、获得途径，等等。标识符体系包括了解析体系。在这个体系里，国家不分大小，一 律平等。国家 内部可以有不同的制度，无论多复杂，都可以交给ORE来负责（听说最近牛排正在研究这个，赞一个！）。目前的技术架构，URI已成主宰，各类Handle 方式基 本上以URI为依托，虽说无奈，倒也无伤大雅，好在DOI等Handle系统也是独立的，离了URI，只要有另外的体系能够取代URI，也能存活。记得 DC的创始人Stu Weibel曾有一阵专门研究取代URI的体系，现在也不知下文了。这些理论问题就不多言了。

因此，有没有URI 是“是不是资源”的 充分必要条件。

至此我们接受了这样一种世界观：网络上的东西，除了有URI的“资源”，就是没有URI的文本字串（literal或string），无 它。（在此我们不讨论“网络上的资源是现实中事物的指代”这样一个哲学跨越，以及由此带来的认识论问题。）

• 任何一个描述，都要明确，描述的对象是什么。无论是什么，都应该是一个网络存在，都有URI。（此乃描述的“资源模型”）
• 任何一个描述，都要明确，描述的是什么。即如果描述颜色，就说“颜色”或“color”，描述作者，就说“作者”、“创建者”或“creator”…

• 任何一个描述，其属性取值可以是互联网上的任何东西，自然就包括有URI的资源和没有URI的文本字串。是“资源”当然也可以像上述属性词一样进行规 范，包括取值体系规范（例如年代的表示规范）和值域规范（从值的列表中选取，例如国家列表、各类复分表，以及大量的KOS词表等）。当然，文本字串是最常见的“值”。（这里涉及 “词表模型”）

上述三个成份，构成描述的基本单元：一个RDF表达，也叫陈述（statement）。

• 一条资源描述可以由多个陈述（statement)组成，即多个属性和属性值对描述一个URI所标识的资源；
• 多条相关的资源描述构成一个描述集（Description Set）。

可以看到，一个陈述可以是资源和资源之间关系的表达式（通过也是资源的属性词表达主体资源和客体资源的关系），每一个作为资源的成份又都可以被其它陈述所描述，具有这种关联关系的描述通常组合成描述集，构成“元数据记录”。Web其实就是各种资源纠结在一起的网状结构，Web这时就从众多服务器构成的网络而转变为无数“资源”连接在一起的网状结构（意义非凡啊！）。联结的末梢常常就是那些字串——字串是无法被描述的，其语义需 要人来解读。

(updated:)与传统的资源描述模型最大的不同，在于明确强调了以下两点：

• 描述的原子性。即每一个陈述必须是由“资源-属性-值(可以是另一个资源)”构成。例如作者是图书的属性，而作者单位是作者的属性，这两者应该用两个RDF语句来陈述。
• 描述的专指性。即属性一定是所描述资源的属性，而不是其任何相关资源的属性。如“作者单位”的属性不能用来描述“图书”资源。

上面所说的，就是DCAM: DC抽象模型的大概。

推荐阅读：宋文等“CDOI规范及其在国家图书馆的应用”《现代图书情报技术》2008.10.1-5，虽然好像国图还没有用，但是这个方案不错。

Related posts

• 演讲：元数据抽象模型与新加坡框架 (17)
• 近期关于元数据编码的讨论 (11)
• Web时代的“元数据方法”(二) (2)
• Web时代的“元数据方法”(一) (2)

感谢雨师对上文的反馈：“高屋建瓴”。我可能总是把屋建得太高，让我慢慢落下来吧…

同样的世界，以不同的方法和角度去看，会呈现出完全不同的样子，不仅如此，甚至会看到完全不同的东西。由于计算机处理能力的提高和认识与技术的进步，人们越来越倾向于按照事物的本来面目去描述事物，只要能认识到这种“面目”。其中，面向对象(”搞对象“？）的方法被认为跟接近大千世界的本原（就不说“本体”了哈），也是当前计算机认识世界的主流方法，以前我们把万物仅仅看成是数字或文字，而世间万物都是相互独立而又普遍联系的，我们为什么不能在Web上建立真实世界的一种”面向对象”的虚拟镜像涅？

都柏林核心元数据抽象模型（DCAM ）就提供了这样一种“面向对象”看待世界的方法。它是为了向计算机描述我们这个世界而提出的，你可以设想向一群外星人解释我们这个世界，你应该如何向他们描述才能让他们理解呢？亚里士多德把世界看成是几种元素，我们到达不了那个境界（深度），只能说：世界都是由“东西”组成的，每个东西都是独立的，东西和东西之间又都是有联系的，认识东西就是认识它的特点（属性），不同的人可能看到不同的特点，把特点说出来就是描述……。然后，外星人就懂了，说：“噢，我们那里也是这样的…”

DCAM是完全基于语义Web的基础RDF模型的，因此可以认为它是语义Web描述这个世界的一种基本方式。

当然，向外星人解释这个世界不应该要求所有人都能干，这样的话”数字图书馆员“也就没有“核心竞争力”了。所以现在DCMI这一帮人（以及爱好者，如本人和平台江 等），以及SW（SemanticWeb）的一大帮人都在日夜奋战，希望能够提供许多方便的工具、平台或环境，使得同志们在按照惯常的方式工作的同时，规范的、外星人能够看懂的语义 描述能够“自动”建立起来。让大量的人文烟鬼继续并且更好地坑蒙拐骗、欺压百姓。

上述的目标距离实现尚有很长的路要走。现在的重点工作，是基于DCAM，建立一整套面向应用的规范体系和架构。

新加坡框架 就是这样提出来的。其目的是为“元数据方案”（DCAP: Dublin Core Application Profile）提供一套理论：一套完整的描述应该包括哪些内容？分别的作用是什么？哪些是定理（例如”用户永远正确“），哪些可以通融…等等。其中最重要的，是有关DSP（Discription Set Profile:描述集方案）的定义和规定。

都柏林核心元数据(DCM)现在是什么东西呢？它以15个基本元素著名，但它早已不是那个东西了，它已经成为一套体系，包括一个模型 （DCAM：Dublin Core Abstract Model，包括）和一套词表（Vocabulary：其中除了元素，又包括子元素——针对属性词来说的；修饰词——针对取值来说的，修饰词还有编码体系修饰词和“取值”修饰词），以及诸多 正在完善中的规定（新加坡框架及其编码）。

欲知后事，且听下文。

Related posts

• 近期关于元数据编码的讨论 (11)
• 演讲：元数据抽象模型与新加坡框架 (17)
• “新加坡框架(Singapore Framework)” (1)
• Web时代的“元数据方法”(四) (7)
• Web时代的“元数据方法”(一) (2)

描述一类资源，首先需要明确为什么要描述，也就是明确需求。需求决定了那些实体需要析出，分别有哪些属性应该被描述，以及实体之间、属性之间的关系是什么。

我们现在的”元数据方案”一般就管到这一步，成果是ER图和属性表，基本方法论就是实体-关系分析。基本功能交给关系数据库来实现。

上面几乎和数据库系统的开发如出一辙。所不同的，我们的目的是建立标准化的、供行业（领域）或更大范围使用的”元数据规范“。即我们希望提供的属性表以及编码方案应该是可被大家共同遵守的、可共享和重用的。

但是上面这种思考方法（“思考范式”），到了Web时代，虽然引入和“神秘的配方”——元数据，也还是不够用的。

1、 Web是一个开放的环境，其功能需求考虑的不光是”自己”的需求，这里的”自己”是指的是本地系统的”相关用户”，借用术语来说：”传统的需求定义只考虑了企业级应用范围内的各类代理（agent）的需求”，Web用户访问特定应用的目的和方式常常会超出系统设定的情境，并且Web用户是不接受”培训” 的，他们会有更多的”替代”选择，甚至你系统的look and feel不好，他们都会走人。因此一个优秀的Web应用，必须能够具有更好的可用性和更强的功能性，必须把更多的可能性置于你的”控制”之下，即便不直接开放，也要提供开放的可能性。

2、这就是为什么很多数字图书馆的Web应用，不能仅仅以”实现需求”为目标，而要深层挖掘”为什么”的原因。特别是现在Web2.0概念引入，需求分析、设计、实现诸多流程合一，用户常常不仅要提出需求，还要介入设计，并且关心如何实现。大多数软件公司希望你明确定义需求，而采用什么平台技术架构来实现，不需要你来关心。这样开发出来的数字图书馆或2.0应用，虽然能够实现功能，但是几乎肯定不是一个“好的应用”。你可以责怪用户没有充分明确需求，很多隐含的需求没有提出来，但系统不好就是不好，谁都有责任。

3、当然这个困境应该是由于软件工程还没有发展出相应的分析方法和设计工具，以及经验流程性的东西能够支撑Web级的数字图书馆或Web2.0应用的开发而造成，也并非任何一方的责任。

4、 Web级的应用对于资源描述的需求可能就常常包含在那些未被提出的”隐含的需求”中，例如Web范围内的语义互操作、数据共享、代码(方案)可重用、永久保存的需要，以及相关技术标准和协议的支持和遵循等等。这些规范的研讨和制定，实际上也是为了将来省事：你只要遵循了我的这些标准规范，许多可能的”隐含需求”就自然而然能够的到满足，即便你的行为是无意识的，好处是奉送的。

因此目前的”元数据方法“（全称应该是”Web资源描述的元数据方法”），已经超越了仅仅提出一套（不管是普适的，例如DC，还是领域的，例如IEEE- LOM或者DCAP）元素集的阶段，因为光是属性元素集是远远不够的。目前DCMI所做的，希望在思想方法上进行一定的统一，即：基于”我们如何看待这个世界”建立描述世间万物的一般方法，而建立起一个一致的思考模型（”抽象模型”）；并且基于这个抽象模型，提出一整套的描述体系和元数据方案。语义Web技术可以提供这种方法的技术基础。可以说，我们正在向语义描述的”统一场论”进发。

Related posts

• 近期关于元数据编码的讨论 (11)
• 演讲：元数据抽象模型与新加坡框架 (17)
• 信息资源描述的“假设系统” (3)
• Web时代的“元数据方法”(四) (7)
• Web时代的“元数据方法”(二) (2)
• 呼唤数字图书馆的“统一场”理论- - (1)

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

承蒙谢涛和江汇泉两位技术大拿与远洋老师在我的博客上发起了热烈的讨论，所涉及的问题实在是在实践中非常重要，却很难武断地进行“推荐”。这里只能就我对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：

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: <dcterms:available>2002-06</dcterms:available>

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

我对如下限定性DC编码方案情有独钟：
<dc:date refinement=”available”>2002-06</dc:date>
它的优势除了在于从结构化上清楚表达了元素及其限定词关系，更是忠实遵循了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

<dcterms:available>2002-06</dcterms:available>
rather than
<dc:date refinement=”available”>2002-06</dc:date>

但在2002/12/02以后的版本中，认为<dcterms:available>2002-06</dcterms:available>优于<dc:date refinement=”available”>2002-06</dc:date>的表述就被取消了。只不过推荐以下格式：
<dcterms:alternative refines=”dc:title”>foo</dcterms:alternative>

<dc:title>
<dcterms:alternative>foo</dcterms:alternative>
</dc:title>

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

我特别好奇，想了解一下作者对这个表述的修订本意是什么？然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”的概念，是否意味着我钟情的类似编码有了更有力的支持？编码类似如下：
<dc:title>正题名</dc:title>
<dc:title refinement=”alternative”>交替题名</dc:title>
从编码结构来看，正题名与交替题名是平级的——等级或从属是通过属性值来体现的。将限定词作为属性值，可以应对不同的需求扩展，更可以忽略这些限定属性，仍体现出大概念描述，这即所谓的向下兼容。

远洋师也是见多识广，能否帮我寻找更多的数据应用实例供参考。我们的本意是寻找一个更合理、更官方（更权威）的数据格式作为我们首先要对付或支持的 格式。当然，如果没有这些数据，只得自行确定。但确定时，能有更多专家指导，总比我们闭门造车，孤陋寡闻弄些贻笑大方的数据格式好些。（找一些实践的数据格式可能很容易，但作用并不一定如您所想得那么大。具体的实例永远都是片面的，同样的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文档之间的关系）

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

<dc:title refinement=”alternative”>交替题名</dc:title>

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

当然，我不反对在软件用户界面上，以某种形式揭示、体型用户关于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，生成相应的数据结构，动态产生表单和相应的展示界面…可能我的想法过于天真了，开发这样的“自动”工具，的确不是很容易）

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

Related posts

• 关于DC元数据的XML模式 (10)
• 演讲：元数据抽象模型与新加坡框架 (17)
• 元素名前缀的作用 (5)
• 代码示例1 (18)
• DC元素的中文翻译 (7)
• 近期讨论（2004年11月23日） (0)

讲这个主题，因为感到有必要，似乎大家都知道，但是理解各不相同。

没有自己的东西，纯粹介绍。也不一定正确，仅供参考。

说明Update：可能slideshare在某些网络以及用某些浏览器无法访问（感谢远洋老师等提供信息），在这里提供ppt下载。

| View | Upload your own

Related posts

• 近期关于元数据编码的讨论 (11)
• Web时代的“元数据方法”(四) (7)
• DC-Lib应用纲要错误一例 (3)
• 近期讨论（2004年11月23日） (0)
• 近期关于元数据的一些讨论 (3)
• 资源集合元数据登记系统 (0)