keven老师所说“我不同意你的看法，如我前面“摘要”中3、4、5所言，这样做正是为了更清晰地表达关系，而且，内容结构与数据文档保持各自的独立性，对于数据的生命周期管理，如对于XML内容结构修改变化的版本管理，有极大的好处。即：可以用不同的Schema读相同的数据，而不需要数据作任何更改”我很赞同。

这是一个原则，对很多系统都适用。

江汇泉说“因而，我认为一个规范的元数据体系，其数据结构的定义就不应该有摇摆性，…”

我认为数据结构一旦定义，自然就是没有摇摆性的。比方说DC决定仅仅干预文档中的“DC能够管辖的部分”，这个原则就是没有摇摆性的。但是它是否对应用人员的心理带来摇摆的感觉，这可不一定。

正因为DC约束了自己的干预程度，其实总体来看DC彻头彻尾就是一个摇摆的定义，在编码结构上。它留出了空间给具体的系统，它绝对不去干预那些领域。这自然都带来了总体的摇摆性。

而且我们限定话题，针对“DC能定义、该定义”的那部分而言，也有一定语义层面的模糊性和可扩充性，说成摇摆性也行。

就如同我举例说明的，“OCLC”的全写是什么？可以有好几个附会的版本出现。类似的情况也发生在格式定义中。最低限度，是格式将来发展时打补丁的需要，我们没有必要歧视这种属性。

具体编码数据中关于语义和其他的线索信息很少，它于是自然允许后面的Schema等等一切设施作出某种新的“附会”和改进。编码数据中的字面信息(例如名称本身)是很明显的，这部分信息当然不能随便动。但是“后台”信息不在数据体里面。我认为这是自然的，有好处。

不同的系统甚至可以对语义作出自己别致的解释。但是也别对这一条太敏感。其实(元素)字面意义已经限定死了，能自由的空间是小空间。元数据集框架的巨大影响还在。这是说语义，而不是结构和形态。

5)

江汇泉举例试图说明XPATH下穷举不同的修饰词多么麻烦，而用冗余的元素名则可以避免这个麻烦。

以我的经验来看，创建那个穷举修饰词列表的事情，可以是软件完成的，而不是要人来次次“手书”。比方说具体系统有一个配置文件，软件写好一个循环程序，随着配置文件的些微变动(这变动当然可以由人进行)，循环自然能穷举当时该穷举的对象。这是“不费力”的。

也好比我们实际运行的系统中，SQL语句中的where子句都很复杂，但正是由程序中的循环过程来创建的，对人来说并不复杂。– 让机器对机器复杂去吧。

这一点小case，得不出“强大优势”的结论。

凡是都要算代价。精于算计不是什么坏事。我要和江汇泉算另外一笔帐：如果所用的编码格式中，XML元素名(对应于DC元素名)和refinement属性的对应关系发生了变化，谁来负责修改数据本身？是江汇泉自己一一调出来数据修改几年呢，还是由一个批处理程序来修改？我们知道，一个具体系统，所用的元素集肯定在不断调整之中，语义和结构都可能调整。

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

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

Like or Dislike: 0 0

我觉得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”就能全文档寻找。

如果一个实际系统把这些编码对象进行了层级管理，但是另一得到这些数据的系统并不“以为然”，把这些对象理解为平坦结构，那么这“最低一层”的语义交换还是可靠的。前一系统关于层级关系的信息，属于“多余的表情”，被后一系统忽视了。这也是一个“好”的例子：毕竟该能交换的东西实现了能交换。

待续。

Like or Dislike: 0 0

1)

keven老师所说“因此DC元数据的XML表达（包括RDF表达）从数据上看起来是平面的，但是其结构和语义是用XMLS来约束的（如果是RDF，扩展的元素用RDF Schema进行定义），因此不能认为它是平面的。”我觉得部分可以认同。

我的理由是，XMLS表达了额外的意思，信息比单纯的数据记录来得丰富。例如keven老师所举的，从Schema中能看出一些蛛丝马迹，让人觉得element和修饰词之间是有“概念层级关系”的。

但是我觉得这些还不够，不是语义信息的全部。仍需要外在的人为的规则来帮助约束。

2)

在谈到语义层级结构的时候，需要注意语义上的层级并不对应数据实例中的结构层级。

比方说，alternative在概念上是title的下位概念，但是并不意味着在编码阶段要在alternative元素外面括一个title元素。

我举一个例子就可以说明问题：人类是从鱼儿进化过来的。一个胎儿在子宫中就模拟经历了全部的进化程序，但出生的时候，已经是一个人，而不是鱼儿。因此对应的说，从概念上alternative和title有“XXX化”的关系，但是在编码的时候，已经“出生”，语义和概念的演绎过程已经结束。也正好比端上餐桌来的菜，许多已经看不出原料。

所以我们眼睛看着一个DC element或者修饰词的编码实体，脑子里面可以想象它们的一切有关语义的事情，但不一定要追求“编码形式上的直白体现”。

但是编码层面也不是不能允许有特别的“结构”。我能想到的例子，就是同一个title，因为语种不同，不同的表现实例之间，它们实际上有紧密的联系– 就是它们实际上都是用来描述一个东西的。好比孩子有大名和小名，看见两个名字并不是说有两个孩子，而是指同一个人。那么这时可以用一个类似这样的XML元素作为容器把它们包装起来。这样的设施在类似RDF这样的“发育良好”的框架下能够得到很好的表现。如果纯XML编码(非RDF等现有框架)要吸取这种特点，我不反对。

总之我暂时反对在编码层用某种结构表达江汇泉所举例的那些语义信息，而不反对用来表达其他的信息。

这里也顺便提到RDF和纯XML编码的关系：RDF看起来是XML，但是某种意义它已然不是XML。就好比豆子酿的酱油，酱油已然不是豆子。豆子不过是其原料。因此纯XML的原始性和自由性，像一片未开垦的处女地，容易让人迷惑，无所适从。

但是从时间和实践的发展看，使用纯XML的趋势是有的。可以理解为人们对RDF等实践后带着更多经验对纯/简单XML格式的一种回归。或者说一种“简约风潮”。

怕单个文字太长，后面再续。

Like or Dislike: 0 0

注：机器抓得元数据value不一定准确，但格式应该是正确的。

Like or Dislike: 0 0

针对“因此DC元数据的XML表达（包括RDF表达）从数据上看起来是平面的，但是其结构和语义是用XMLS来约束的（如果是RDF，扩展的元素用RDF Schema进行定义），因此不能认为它是平面的。”

我的看法：XML表达，从数据来看都是线型的。但线型的数据，可以简单表达一层或二层数据结构，也可通过嵌套，表达出立体的、多层结构。

从数据交换来看，离开了XMLS的XML是无意义的，即使同采用了dc:title这类DC名称，即使从数据样例来看完全一样，从理论上讲，也不能肯定其是完全一样的。只有符合同一个XMLS的约束和定义的数据，才能说它们是一致的。但并不能说因为采用XMLS约束了平面的数据，所以数据就变成了立体的而不是平面的。因为XMLS仅是对数据的一种约束和定义，数据是平面的，则XMLS就表达了这种平面结构的定义和约束，反之，则XMLS就表达了这种立体结构的定义和约束。

针对“这也就是说，DC元数据的形式化描述中，dc:alternative看起来与dc:title处于一样的地位，但实际上是完全不一样的，在XML文件的根元素指向格式解析模式中（通常是一个形式化的元数据应用纲要），可以明确它们的上下位关系。”

我的看法：如果是当前DCMI推荐的限定性DC形式化结构，即dc:alternative看起来与dc:title处于一样的地位，那么，在XMLS中，也是一样的地位，而无法确定它们的上下位关系。这点我将在后面的XMLS分析中进一步说明。

关于我所谓“总在语义层面中纠缠”的感慨，仅是从纯技术层面角度来看，信息编码的根本目的仅是为了让计算机更易识别，所谓可读性更主要是指数据结构清晰无歧义、计算机处理效率更高。而不是指标识符带语义以及这种结构表达出某种语义——因为这些东西是人为赋予它们的。

所谓语义，我看用鲁迅谈及《红楼梦》的一句话来评论比较贴切：“经学家看见《易》，道学家看见淫，才子看见缠绵，革命家看见排满，流言家看见宫闱秘事”——计算机将元数据编码组合后，它们表达的语义，完全视用户或行业的约定俗成而定罢了。我是赞成谢涛同志所谓“大家讨论的许多问题可能确实和编码层面无关。因此建议可以先把编码层的实践方向和细节搞清楚，从而就可以开始行动了，具体语义和如何细节著录的事情可以继续吵，但是软件纹丝不动”的观点。都没有一个确定的编码组合，何来语义？“我”、“爱”、“你”——没有一个固定的组织方式，那么可以表达出“我爱你”、“你爱我”甚至引申为单相思或两情相悦等多种语义。

当然，结构清晰无歧义的编码，可以帮助人们实现语义的表达，这就是我们追求某种合理的数据结构或数据封装的原因。

针对“这与目前成熟的计算机软件系统体系架构有关，具体的应用都要采用成熟的技术，因此直接用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的定义，并获知这两个词汇间的关系。这种关系并不是通过数据格式或编码表现出来的，所以我说它们是隐含的。

针对“我不同意你的看法，如我前面“摘要”中3、4、5所言，这样做正是为了更清晰地表达关系，而且，内容结构与数据文档保持各自的独立性，对于数据的生命周期管理，如对于XML内容结构修改变化的版本管理，有极大的好处。即：可以用不同的Schema读相同的数据，而不需要数据作任何更改”

我的看法：可能是因为我的“隐含”说法让你误认为我不重视数据以外的XMLS这个内容结构定义文件。事实上恰恰相反，我更关注这个XMLS。有时，为了表述元数据元素间的关系，在言语的贫乏下，XMLS语法就成为我的救兵。对于你“内容结构与数据文档保持各自的独立性，对于数据的生命周期管理，如对于XML内容结构修改变化的版本管理，有极大的好处。即：可以用不同的Schema读相同的数据，而不需要数据作任何更改”的表述，我想补充一点理解——结构定义与数据文档确实是相互独立的，但它们是相辅相成的。关于它们间的关系，似乎容易引起类似先有鸡还是先有蛋的争论。而我认为没有规矩不成方圆，事实确定一个结构定义，以此规范相应的数据文档更宜。因而，我认为一个规范的元数据体系，其数据结构的定义就不应该有摇摆性，所谓用不同的Schema读相同的数据，而不需要数据作任何更改的“好处”无从谈起——因为只要不同的Schema定义的数据，即使看起来相同，也应该看作不同的数据（你如何确定其中可选的数据差别呢？）——这点类似你评论谢涛的“一个修饰词只能修饰一个元素，即使它们形态上一样，也必须认为是不一样的”。再从语义打个比方，同是title，对于人事管理体系来看，它可能指的是头衔，而对于图书馆体系来看，它可能指的是题名。

实际应用中，对于资源的描述内容，即数据文档可能有不同，但应该且必须受同一个Schema文档的规范和约束——我的这个表述，可能与你“可以用不同的Schema读相同的数据，而不需要数据作任何更改”的表述刚好相反。用不同的Schema读相同的数据，正是我认为导致DC应用混乱无序的最大症结。林林总总的数据样例，居然无法用同一种Schema来定义或表述其结构。不同人的眼中有不同的哈姆雷特——DC应用中的这种摇摆性，看起来讨好了不同的观点，将只要标榜自己是DC的应用都纳入自己的阵营，貌似强大和影响广泛，但这种阵营总是不堪一击的。于是，采用无歧义的简单DC，就被垢病为不足以详细描述资源；采用随意且不经约束的限定性扩展，就被垢病为跟扩展MARC字段有什么两样？先进性何在？联想起“一个中国，各自表述”，看起来相安无事，但统一遥遥无期。如同谢涛所说，不管什么样的数据，计算机都可以处理。但有某种规范和唯一性，才有数据交换互操作性——即使这种规范和唯一性有些不合理，为了保证数据交换，我们首先得认同它。当然，如果理由充分，完全可以用更合理的规范和唯一性来取代旧的规范和唯一性。或许这也是我特别希望在行业应用尚未起步或大规模起步时，能通过交流或辩争，提前形成一个更合理更规范的数据结构定义，从而防范日后的积重难返——简单的比方，LCMARC定义之初，由于没有意识到计算机的强大，在字段内容中添加了ISBD分隔符。数据的积累，导致取消分隔符或兼容它的成本过高，然不取消它则著录成本也不菲。

那么，现在我试着分析一下当前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文件能看出平面数据的立体结构，以及看出显式表达出元素与其限定词间的关系是不太成立的。
上述两种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文件，将无法验证旧数据了。当然，把旧数据按这个修订规则作一下数据转换、重构一下检索点也是能解决问题的。

再看看我推崇的数据格式及其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仅是为了照顾语义:-)

再看看表达同样语义的，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:title”
采用XPath对带限定词的日期寻址:
创建日期=”/dcterms:created”
采用XPath对带限定词的日期概括寻址:
其它日期=”/dcterms:created”+”/dcterms:valid”+”/dcterms:available”+”/issued”+”/dcterms:modified” //如果有更多限定词，需要修改寻址方式以实现穷举
采用XPath对所有日期概括寻址:
所有日期=”/dc:title”+”/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:title[not(@refinement)]” //不带refinement属性的即为无限定词的日期
采用XPath对带限定词的日期寻址:
创建日期=”/dc:title[@refinement='dcterms:created']” //refinement属性值等于dcterms:created的即为创建日期
采用XPath对带限定词的日期概括寻址:
其它日期=”/dc:title[boolean(@refinement)]” //凡带refinement属性的即为日期的限定词，包括dcterms:created，dcterms:created，dcterms:valid，dcterms:available，dcterms:issued，dcterms:modified
采用XPath对所有日期概括寻址:
所有日期=”/dc:title” //忽略refinement属性，包括dc:date，dcterms:created，dcterms:created，dcterms:valid，dcterms:available，dcterms:issued，dcterms:modified

前后对比，难道还看不出后一种除了在编码结构（注意，不是数据内容）上多些冗余，但在显式体现DC元素及其限定词间关系、表达“向下兼容”、以及系统寻址稳定性上，体现出强大的优势吗？

Like or Dislike: 0 0

头晕是因为一下子看到这么多东西，有些反应不过来。而且看到数据样例和Schema是要费脑筋去想的，才能理解消化，需要一个过程。

谢谢提供的线索，我会去关注。

至于软件公司去扩展元素或者子元素，完全是因为在国内如果我们要推广软件产品，目前的局面，势必要包办数据规范的一些草创性的事情。

这里索性把话题再展开一些：我对江汇泉念叨过，当年做MARC编目软件的时候，北图已经发行了磁盘版的ISO2709数据，图书馆也在积极准备应用，所以没费什么脑细胞就埋头做软件，解决具体问题，一路就过来了。

而现在说DC应用，我们面对的可行的市场仅仅是图书馆传统业务应用它。我感觉，相关领域中现在大家注意力比较集中的某些数据量很小(可能却很有名)的科研课题，反而是闹着玩的，没有商业投入，也没有什么社会影响，甚至连用户是谁都不关心。

照理说促进DC的应用，似乎应该是那些大图书馆的事情，而不是小图书馆的事情。不过我们在长期推广编目软件的过程中，逐渐发现小图书馆恰恰有对MARC格式的明显抱怨和对类似DC这样新型格式的渴望。

一些小图书馆用的特殊软件，什么数据格式规范也没有，数据也无法交换，唯一的优点，就是软件小、维护简单。我想，如果把它们稍稍往DC方面引导一下，不就是标准化了么，既不防碍原有的简单性，也大大提升了层次。这是值得去做的事情。对于公司，赚钱大家都在赚钱，但是某些方面有没有前瞻性，有没有技术和策略方面的良心，还是有区别的。

完全可能出现“农村包围城市”的局面，在小图书馆先开始应用DC编目。原因无它，只是因为表面上至少DC看起来“简单”，有很明显的商业价值。

所以，在目前这种情况下，软件公司不得不承担吃透数据格式，替用户组织人员培训，这些原本很吃力的事情。

应当说这种局面，也许反而容易激起参与者的历史使命感。空白就是机会。若因为这个缘故让开发人员多接触一下数据格式方面的话题，我想也是因祸得福了。

~~~

编写软件，自然是要有灵活性和柔韧性。这方面，我们的新一代系统是完全基于XML的，DC应用不过是其中的一种，我们并未开发什么“专用DC系统”。所以，在格式变动方面，我们不害怕，因为系统柔韧性很强，变动很容易。

不过反过来却是，基本设定了“应用DC”之后，发现两眼一摸黑，在具体DC怎么去应用方面，有些找不到北。好比拿着一把很快的刀，却看不清要杀的对象。

在大部分“有用的、具体能卖钱”的软件创建过程中，我们也会附带创建一些通用的小工具。类似通用DC IDE编辑器环境这样的课题，我很感兴趣。

我自己在开发全面基于XML的新一代数据库软件环境过程中，曾经开发过通用的XML Editor，有幸对XML文档结构和namespace有第一手的实践 — 实践后的感觉是不一样的。江汇泉也设想过XMLS直接参与编辑器界面生成的技术环节，可惜因为开发成本和精力原因，一直没有机会动手实做。

对于具体一个软件应用系统，和附带产生有更广泛用途的通用软件工具两个方面，我们都怀有兴趣。当然如果精力有限，那就优先在前一个方面投入精力。

Like or Dislike: 0 0

Like or Dislike: 0 0

keven老师给出的大量资料，粗看了一下，第一感觉就是头晕，打算找时间仔细看看，现在除了表示感谢，还说不出什么。

关于XML文档的Schema，这里再说两句感想，请指正：

1) 对XML编码实现，DC的一个用意，似乎显然是希望DC的那些element也好terms也好，其namespace明确，和文档中来自其他namespace的东西友好相处。

就是说，你用DC当然可以和自己扩展的(或者早于DC以前就存在) 的XML结构混合使用。若不是这样，DC就没有什么用了，把自己的应用之路堵死了。我想DCMI不会去做这样违背自然和直觉的规定。

所以，DCMI推荐或者示范的XML编码Schema，一定只是描述了DC所能管辖的局部，这个“局部”是指相对于实际应用中XML文档的“全部”而言的。

Dublin Core的这个Core很有意思，大概是说我在中央，你们在外围，你们要扩展的描述性对象，不要和我冲突，在我能力不及的地方你们可以扩展。

这样，“中央”代表了重要的交互性和一致性。也就是说，在15个元素问题上，大家取得共识，不再竞相单独扩展，对语义上的共享和交互有好处，因此才谈得上数据交换。

2) 我最近正在关注的一个软件项目中，涉及到普通图书采用DC进行编目实践的具体问题。首先，DC 15个元素肯定要采纳。第二，dcterms已经公布的，尽量采纳，因为似乎没有必要再另起炉灶。第三，自行扩充其余的必要的。

第二点意见是不是对，请指正。

我是这么“逻辑”的：假定第二点不存在，只能采取第三点的做法，就是自己在自己的namespace中扩充描述性对象 — 我这里还只敢说在XML文档编码实现层面它们是一些实在的“东西”，还不敢把它们叫做“元数据(外围)扩展”，既然要扩展，而且有一部分和dcterms的已有概念对象重复，那何不直接采用dcterms呢？因为dcterms似乎采纳的广泛性要比我自己扩充的要高(DCMI上写出来了，世界的另外一些角落我想总是有倒霉蛋会去用的)

因此数据可交换性会增加那么一点点。当然如果编目方面的元素(修饰词)集如果有权威机构去拓展定义、推广和维持，我也是乐得用现成的。

从编码层面，我觉得除了15个元素，其他的都是不那么正规的，可以理解为DCMI公布的terms或者自己扩展的termes。因为我自己要扩展element层次对象的可能性很小(这个工作已经被DCMI暂时给做穷尽了)，绝大可能是扩展所谓修饰词也好、子元素也好。

所以简单理解，我自己的namespace中的概念元素，闭上眼睛想肯定都是一些修饰词。这局面和DC 15个元素被批准为标准，而它的修饰词还不是标准，看起来觉得也是相协调的。

3) 从某种角度，我把采用了DC修饰词看作对15元素数量的扩展。简单说就是15元素不够用，我扩了也好DCMI扩了也好，都是数量上的进步。

当然可能有人会说，所扩的修饰词并未增加什么概念宽度范围，而是在概念的精细描述上加深了深度。这个我同意。上面说“数量增加”是一个粗糙的说法。

在实践工作中，肯定大量对DC 15元素使用的“不满”在于嫌“精度”不够，而不是广度不够。

但是这也不见得是缺点。从简单应用看，这是优点。从复杂应用看，显然Core本身是不够的。Core的一层意思是概念的广泛适应性，15个元素的概括面还是很理想的，这样Core并不寒酸 — 反而可以说“普适”。但是“数量”上很少。当然这也不是Core的过错，因为它毕竟是Core。所以第二层意思，是深度上本来就需要别人扩展？Core本身就是在说“单独用我肯定不够哟”。

Like or Dislike: 0 0

Like or Dislike: 0 0

有空再讨论. 希望继续。

Like or Dislike: 0 0