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

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

从软件实现的路径来看，首先是形态上的理解和兼容，能够存储数据，能够直白地检索。

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

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

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

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

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

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

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

从DCMI目前提供的dcterms语义、形态定义看，类似alternative这样的修饰词在语义类属上，只能属于一个element，而从未发现有从属于二个或者以上element的例子。我这个感觉如果有误，请指正。

从我看到的这个现象，侧面证明了所谓修饰词的“名词”属性。也就是说，在讨论中，大家摆开了揉碎了说，可能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这样的语义表达方式笨拙，那也没有办法。不过至少，这种“初等”的表达方式，是目前软件开发技术所习惯的，虽然不高明，但是还可以用。

另，至于采用refinement(s)还是qualifer(s)作为编码中的XML属性，由于不涉及到结构，不属我关注的重点——类似“下岗”与“失业”，我们能理解它们意思相同即可。

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

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

远望师也是见多识广，能否帮我寻找更多的数据应用实例供参考。我们的本意是寻找一个更合理、更官方（更权威）的数据格式作为我们首先要对付或支持的格式。当然，如果没有这些数据，只得自行确定。但确定时，能有更多专家指导，总比我们闭门造车，孤陋寡闻弄些贻笑大方的数据格式好些。

对远望师的指点，先表谢意。

2. 而在真正的有*等级*的元数据标准（例如几乎所有的其它标准， LOM, CDWA-lite, VRA Core4.0, PBCore, 等等）中，sub-elements必须隶属于上面的element。在做记录过程中这个等级形式很严格，数据值（values) 只能放在最‘子‘层。这是与XML的语法一致的。
但如Keven所说，有等级的结构可能会影响数据的重复使用，也可能违反1:1原则，在机器交换中产生问题。这要看哪个元数据标准做得好了。
抛砖引玉，请大家继续讨论。

我曾花了好长时间才逐渐弄明白原来DC谈论的修饰词，就是refinemented element。

系统可以将最本质的元数据处理好后，很容易采用某个定型的容器进行包装。

RDF是元数据吗？这是一个问题。