所给出的DC-AP URL很重要，我想江汇泉看了后近期该有事要做了。

一直以来我脑子里面都是乱的，没有功夫静下心来仔细看看周围，连DC-AP都还是头一回听说(或者以前听说过后来又忘记了)，感觉颇有些荒唐。

这次讨论中涉及的资料，后一段我们会慢慢消化。在这里对远洋老师提供信息表示感谢。

这与我关注的语义限定词为语义精致或细分的概念似乎有冲突。

另，感谢远洋师提供的VRA Core信息，查看其数据样例，type属性的应用类似我的理解：
full view
如果这样，我理解的DC修饰词（更多是我认为应用中需要扩充而不是当前DC那几个有限的修饰词）似乎应该类似远洋师所说的*类型*了（）——不同的元素也可以用‘type’这个属性，只是规定的values会不一样。

谢涛批评我的一点现在比较认同：即，如果打着DC的幌子，应用所谓的DC限定词，就得用定义的，即使其数量有限。想在其上做文章，扩展出来的，都不属于DC范畴了。

另外，不同的元素也可以用‘type’这个属性，只是规定的values会不一样。VRA Core 4.0后面附了很详细的属性值表，同一个type， 在不同场合有不同的值。
VRA Core 4.0 见：http://www.vraweb.org/projects/vracore4/index.html

又：有很多工业标准都不会去变成NISO和ISO标准。W3C的recommendations虽然没有称为国际标准，实际上比什么都有效。但是想成为W3C标准的投票会员要花大钱，所以图书馆协会、情报学会什么的一般都没有办法加入。NISO也不便宜，但比起W3C来好得多，虽然这样，近年来还是有些图书馆协会只好退出。

注意“<rdfs:subPropertyOf rdf:resource="http://purl.org/dc/elements/1.1/title"/&gt; “这一段。

<rdf:Property rdf:about="http://purl.org/dc/terms/alternative"&gt;
<rdfs:label xml:lang="en-US">Alternative</rdfs:label>
<rdfs:comment xml: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/"/&gt;
<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"/&gt;
<dc:type rdf:resource="http://dublincore.org/usage/documents/principles/#element-refinement"/&gt;
<dcterms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#alternative-002"/&gt;
</rdf:Property>

DC15个核心元素的语义或编码基本没有什么异议，这就是它之所以为核心、之所以容易被接受的原因。而其修饰词，出来伊始就让我感觉有点不伦不类——扩得这么少，怎么满足应用需求？冷静一想，原来其扩展原则才是精髓，而那几个有限的修饰词，可以看作是DCMI为了阐述其扩展原则而定义的一种抽象示例。
也就是说，只要在符合DCMI扩展原则下的应用扩展，都应该是合理的——从语义区分的角度，只要为其赋予了namespace即可。有了namespace，就把它从DC中择出来了。
所以，dcterms虽然包含有DC15个元素，它也是与DC不一样的元素集，即它不是DC！
这也是我为什么宁愿在refinement属性值中用任意字符串而不单独定义具体DC修饰词的原因——因为除了具体应用需要确定具体的修饰词外，抽象的DC体系，只要是细化的元素语义，都可视为DC修饰词。包括dcterms元素集中的元素以及自定义元素。

关于“dc.xsd和dcterms.xsd看起来是不支持DCAM的，因为所有的属性都是作为Literal的”——我认为并不说明DCMI有局限，因为对于DCMI的编码体系限定来说，可以采用XMLS的数据类型派生方式，比如xsi:type=”DDC”，可以说明dc:subject的值只能是比Literal更细化的、属于DDC词表中的词汇，这是一种限定派生。还有一种扩展派生，即声明属性是在Literal基础上，更具有子元素，比如：
<dc:description></dc:description>
这是不带派生数据类型声明的，常用方式
<dc:description xsi:type=”dcterms:URI”></dc:description>
这是带限定派生数据类型声明的，即属性只能为URI格式而不是任意字符串。
<dc:description xsi:type=”my:HTML”></dc:description>
这是带扩展派生数据类型声明的，即属性不仅为任意字符串，且其中包括子元素（HTML格式即为这种字符串与置标符混排）。

在思考如何表达关联资源时，常用的以指明关联资源URI的方式，在展示数据效果时略显单薄，所以我觉得可以用一个扩展派生类型，通过允许嵌套DC元素的方式，就可以在数据冗余与系统效率中寻找一种平衡了：
<dc:relation xsi:type=”my:nestedType”>
  <dc:title></dc:title>
  <dc:identifier xsi:type=”dcterms:URI”></dc:identifier>
</dc:relation>
当然，这只是一种系统内部处理方式，对于普通性应用交换来说，可以在输出时，转换为常见的数据格式即可。

leonz师说的极是，我与谢涛在这里废话连篇，搞得博主另起炉灶，单摆一桌，入席者不停挪板凳，影响食欲:-)

另，关于我回复内容享受“待审核”待遇，还不是因为我废话特多，系统对于喧宾夺主的人的一种抗议嘛——这点谢涛就比我聪明，把话题分成待续说。