小刘你好。看到你贴出来的内容，有以下几个问题想跟你深入交流一下：
1、采用DC元数据来描述特色资源，是一个很好的办法。描述特色资源，仅用简单DC是不够的，所以多采用DC限定（修饰），以使元素语义更精炼（所谓的语义限定）、更规范（所谓的编码限定）。如何用表达DC的语义限定，常见的是采用另一种命名空间的语义，比如dcterms中的alternative，就是其它题名的语义。那么，这个语义，形式上是等同于dc中的title，因而，采用我们的DC编目功能，在界面定义配置文件“dcdef”中，你那些“中文题名”、“英文题名”、“其它题名”的描述层面，如果是你们理解的DC限定词（随后再交流对于描述语种的表达方式），也得类同于dc:title一样进行定义，如：
<element name="dc:title">
<caption lang="zh">题名</caption>
<caption lang="en">Title</caption>
</element>
<element name="dcterms:alternative">
<caption lang="zh">其他题名</caption>
<caption lang="en">Alternative Title</caption>
</element>
即元素与元素限定，都是元素。
2、在DC中，是可以采用多种语种对资源的描述层面进行描述的，这些多种语种的描述信息，显然都是某个描述层面，只是其描述语种不一样。例如都是正题名，只不是一个是英文的正题名，另一个是中文的正题名而已。那么，更合理的界面定义，应该是采用常用的元素语种限定（修饰），这个配置定义，为节省配置文件尺寸，我们没有放在某个元素下，而是独立放置于配置文件后面的languages元素中：
<languages>
<item name="zh">
<caption lang="zh">中文</caption>
<caption lang="en">Chinese</caption>
</item>
<item name="en">
<caption lang="zh">英文</caption>
<caption lang="en">English</caption>
</item>
</languages>
也就是说，当你用中文描述正题名时，在相关元素，比如dc:title的界面后，有一个语种下拉选单，你选中“中文”即可；如果是用英文描述正题名（即你们所谓的“英文题名”）时，选择“英文”即可，实际产生的记录XML格式如下：
<dc:title xml:lang="zh">中文正题名测试</dc:title>
<dc:title xml:lang="zh">英文正题名测试</dc:title>
3、关于编码限定，由于某些描述层面，涉及到用规范词或规范体系中的取值而不是自然语言描述，那么，这就是常见的DC编码限定，我们的dcdef配置中，将其置于元素定义下，比如：
<element name="dc:subject">
<caption lang="zh">主题</caption>
<caption lang="en">Subject</caption>
<types>
<type name="CT">
<caption lang="zh">汉语主题词</caption>
<caption lang="en">Chinese Thesaurus</caption>
</type>
<type name="CLC">
<caption lang="zh">中图法分类号</caption>
<caption lang="en">Chinese Library Class</caption>
</type>
</types>
</element>
<element name="dc:date">
<caption lang="zh">日期</caption>
<caption lang="en">Date</caption>
<types>
<type name="dcterms:W3CDTF">
<caption lang="zh">W3C日期时间格式</caption>
<caption lang="en">W3CDTF</caption>
</type>
</types>
</element>
在用dc:subject对资源作主题分析中，可以采用“汉语主题词”、“中图法分类”等规范取值；还比如采用“W3CDTF”格式作为dc:date的描述格式等等。
4、还有我个人的理解，对于DC的限定，可以不采用另一个命名空间的元素，比如不采用dcterms中的元素——虽然其广为人知。但因与dc命名空间混用，导致理解困难——打个比方，假如dc:title是“人”，dcterms:alternative就是“好人”，如果都按元素来理解和表达，好比说：“我是人”，“我是好人”，根据常理，如果“我是好人”，已经表达出了“我是人”的概念，用不着多此一举进行描述。而我们常见的描述层面中，有正题名、有其它题名等等描述要求，那么，好比有这样的一个描述体系，它具有dcterms:title和dcterms:alternative两个元素，前一个就是“正题名”定义，后一个是“其它题名”定义，注意，这里的dcterms:title并不等于dc:title了。
也就是说，我认为当前dc命名空间与dcterms命名空间混用的元数据描述中，已将dc:title中的语义弱化成dcterms命名空间中级别与dcterms:alternative元素一样的某个题名概念，比如所谓的“正题名”。它们两并不能体现出上下级关系或内在联系。
那么，如果要想体现出宽泛概念与其精练概念的层次关系或语义联系，那么，我认为DC的语义限定，也应该是采用类似其编码限定一样的表达方式，即在XML中作为描述元素的一个属性，比如xsi:type属性名值是编码限定的表达，那么，另外一个属性名值，比如refinement属性名值就是语义限定的表达，XML格式如下：
<dc:title xml:lang="zh">中文之题名测试</dc:title>
即当不清楚这个题名是什么题名时，尽管用不带语义限定词的方式表达它。当某天，我们认识到它其实是翻译题名（注意，这是资源本身的题名，而不是我们编目人员用另一种语言来描述它的题名，后者更应该用描述语种限定来表达）时，我们仅需修改当前描述，为其添加上相关的语义限定表达，XML格式如下：
<dc:title xml:lang="zh" refinement="translate">中文之题名测试</dc:title>
也就是说，现在的“中文之题名测试”这个描述字符串，表达的是用中文语种进行描述的、这个资源的翻译题名——是资源本来具有的翻译题名，可能这是一个其它语种编写的资源，它具有中文题名。这里，我故意用这种复杂的例子来阐述我的观点，希望不至于让你困惑。
然而，由于这只是我的一个观点，所以，当前系统DC元数据编目测试功能中，只具有元素的编码限定定义配置，即在element元素下，采用types子元素来表达并形成编码限定的下拉列表值；也只具有资源描述的语种表达定义配置，即前述的languages元素，相关dcdef配置文件如下：
<elements>
<element name="dc:source">
<caption lang="zh">来源</caption>
<caption lang="en">Source</caption>
<types>
<type name="dcterms:URI">
<caption lang="zh">统一资源标识</caption>
<caption lang="en">URI</caption>
</type>
</types>
</element>
</elements>
<languages>
<item name="zh">
<caption lang="zh">中文</caption>
<caption lang="en">Chinese</caption>
</item>
<item name="en">
<caption lang="zh">英文</caption>
<caption lang="en">English</caption>
</item>
</languages>
并没有给你们扩展一个语义限定的属性列表值，即假如我的观点得到业界或客户的认可，那么，是可以考虑在dcdef定义文件中，增加这样的定义：
<element name="dc:title">
<caption lang="zh">题名</caption>
<caption lang="en">Title</caption>
<refinements>
<refinement name="alternative">
<caption lang="zh">其他题名</caption>
<caption lang="en">Alternative Title</caption>
</refinement>
</refinements>
<types>
<type name="pinyin">
<caption lang="zh">拼音</caption>
<caption lang="en">pinyin</caption>
</type>
</types>
</element>
即在element元素下的refinements元素下采用refinement元素表达这个dc:title的语义限定，注意，语义限定值一样可以采用另一个命名空间的语义元素，比如dcterms:alternative——如果你认为广为人知的dcterms:alternative的语义更不易让人误解的话——嗬嗬，我又在故意用复杂的例子来“赠送”另一种交流话题了。
5、回到你的问题上来，假如抛开以上理论概念，按你配置出来的dcdef，生成的XML记录，你那检索点配置方式应该没问题呀，因为你的XPath表达式：
//dc:title[not(@xsi:type)]
意思就是提取不含xsi:type属性的所有dc:title元素内容，假如你能保证你的元素XML中，确实没有xsi:type属性，应该没错的。
但是，既然界面中有这个下拉列表，有可能你不选择内容，也会形成一个空值的@xsi:type属性，所以，你的[not(@xsi:type)]的意思是找不带有xsi:type属性的dc:title，就自然不能提取内容了——可以改成[@xsi:type!='']判断试试。
——这纯属在你的样例基础上探讨的。所以，注意，严格意义上，不含属性和属性值为空是不一样的概念。