This entry was posted
on 星期天, 十一月 25th, 2007 at 12:07 上午 and is filed under 元数据, 数字图书馆.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
始终在想，为什么这么几个国字号的项目，总在语义层面中纠缠，就不能直白告诉我们如何在计算机中兑现和确定一个数据交换格式呢？作为系统开发商的我们，等得花儿都谢了。如果我等草根阶层，在没有官方的指导下，弄些自定义的数据格式，又担心才思浅薄，误导我们的用户，更被日后官方格式制订者耻笑。所以，今天借刘所的宝地，提出几个问题，希望见多识广的朋友们能告诉我某些具体应用中的数据格式或处理方式，先谢过了：
1、请问DC应用中，如何处理汉语拼音？我得理解是应视汉语拼音为描述内容的规范体系或编码方案，采用类似：
san guo yan yi的编码格式。请朋友们告诉我，是否在某个具体应用中看到过汉语拼音的编码格式，其数据样例是什么样的呢？
2、简单DC数据的XML编码，基本上没有异议。但对于限定性DC，就没看到有多少具体应用。但实际应用中，简单DC是不足以承担具体应用需要的更复杂的描述需求。那么，请问各位朋友，能否提供些具体应用中产生的限定性DC数据的XML编码样例？
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:
事实上，在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
丫枝 Said on 十一月 25th, 2007 at 9:38 上午 quote
OA万岁！
Like or Dislike:
0 
0
[回复]
明蓝 Said on 十一月 25th, 2007 at 12:34 下午 quote
期待K师对DC元数据标准规范体系进行详细解释，最好能给个实例，或者一正一反更好给我们以感性认识。
Like or Dislike:
0 
0
[回复]
没睡醒 Said on 十一月 25th, 2007 at 9:10 下午 quote
急，看不了啊，为什么？
Like or Dislike:
0 
0
[回复]
远洋 Said on 十一月 25th, 2007 at 10:51 下午 quote
高密度，高精度，第一时间… (还有什么词可以形容？）
一个问题：元素修饰词不知道是哪个英文词？Qualifier还是refinement? 不过不论是哪个，都不应该是sub-element （子元素），对吗？
一个观点：建议国内图书馆界同行从核心元素、抽象模型、应用纲要方面遵循DC的建议，这样能保证将来各种资源的元数据的整合和互操作。但是也希望大家不要拘泥于DC所画的框框。每个行业、专业要处理的资源不同、有不同的主要目的，条件和环境也不同，不可能有一种方法和标准来解决所有的问题。大多数元数据标准为了解决本行业的问题都没有限定在DC这种平面型的结构上，而是采用等级结构(元素–子元素–子子元素 以及通用和专用特征attributes），这种等级结构结构是与XML的定义和语法相符合的。所以说，DC只是代表一种方向，一种模式，整个元数据世界里还有很多成功的实例可以参考。
注：Keven, 你的PPT在IE上看不了，要从Firefox看。
Like or Dislike:
0 
0
[回复]
keven Said on 十一月 26th, 2007 at 12:23 上午 quote
修饰词指Qualifier，元素修饰词Element refinement，编码体系修饰词Encoding Scheme，…来自http://dublincore.org/usage/documents/principles/，这样的翻译的确不太严格，但我想不到更好的翻译，因为按字面翻译恐怕更引起国人的不理解（如refinement与qualifier的区别联系我还不太知道）
我感到DCAM(抽象模型)之所以重要是因为它就是RDF的语义表达模型，XML是不表达语义的，可以用多种方式表达DCAM中的各种约束关系，但各有利弊，并不是等效的，因此要发展元数据在语义Web中的应用，严格实现DCAM对于DCAP来说是非常必要的。当然严格采用符合DCAM的RDF编码，到具体应用实现时也会出现如何开发系统的问题，目前的确是太超前了点。
Like or Dislike:
0 
0
[回复]
远洋过客 Said on 十一月 26th, 2007 at 1:15 上午 quote
非常好的解释！是不是有空再普及一下RDF和RDFS? 特别是通过比较说明为什么元数据元素集要用RDF/S来做schemas,不光是XML schemas.
PPT中关于DC名称（而不是标签）的翻译建议很重要，坚决支持！我想DC元素名称(name),即token， 就像马克的字段名一样，在信息交换中如果不是100，245这样的名称，而是翻译的各国的标签名，就没法交换了。DC采用namespace保证了其每个名称的唯一性，这一点可能是每个希望参加交换的元数据标准首先要解决的问题。（如果是供内部用的，不考虑交换，则不一定要求。）
Like or Dislike:
0 
0
[回复]
平台江 Said on 十一月 27th, 2007 at 1:50 下午 quote
刘所此沙龙是高朋满座，交谈甚欢。我也鸹嘈几声：
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的编码格式。请朋友们告诉我，是否在某个具体应用中看到过汉语拼音的编码格式，其数据样例是什么样的呢？
2、简单DC数据的XML编码，基本上没有异议。但对于限定性DC，就没看到有多少具体应用。但实际应用中，简单DC是不足以承担具体应用需要的更复杂的描述需求。那么，请问各位朋友，能否提供些具体应用中产生的限定性DC数据的XML编码样例？
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:
2002-06
推荐DC元素与元素限定词都编码为XML元素，采用QName，通过所引用的namespace来隐含表达元素与限定词间的关系。对于这点我有异议，采用XML编码是DC元数据的一种进步，因为XML是一种高度结构化的编码方案，通过XML结构，可以在数据内部清晰表达出元素与限定词间的关系，为什么非要采用外部的隐含表达呢？“言之不足，手之舞之，足之蹈之”——辅助手段是在主要手段不足时用，为什么非要舍本逐末呢？
我对如下限定性DC编码方案情有独钟：
2002-06
它的优势除了在于从结构化上清楚表达了元素及其限定词关系，更是忠实遵循了DC向下兼容原则——具体应用中，随便你扩充或忽略限定词，数据结构稳定、信息价值不会丢失。而推荐格式，除了少些数据冗余（这种数据冗余是结构上的而非信息内容上的，所以计算机处理时完全可以忽略不计），我看不出有别的优点。——当然，从语法转换来讲，这两种格式是等价的，但从对DC的理解来看，推荐格式显得比较矛盾。简单来讲，既DC明确了元素限定词不是元素（语义重叠的不能扩展为元素），那么，从形式来讲，用XML元素体现DC元素，再用XML属性体现出限定词，这才有主次和差别之分嘛。何况，同为DC限定体系的编码规范体系限定（encoding-scheme），推荐又采用XML属性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
2002-06
rather than
2002-06
但在2002/12/02以后的版本中，认为2002-06优于2002-06的表述就被取消了。只不推荐以下格式：
foo
foo
明眼人都看得出，上述两种方式确实既冗余，又没“意义”。
我特别好奇，想了解一下作者对这个表述的修订本意是什么？然E文水平有限，担心对方听不懂——还望刘所或与我同样好奇的朋友替我与作者交流一二，并将结果转告与我——再次谢谢了。
最近，公司在开发DC编辑系统的“等米下锅”（寻求一种官方的、广泛应用的数据格式）过程中，为了降低开发成本，争取兼容常见DC数据格式过程中，有些慎重而严肃的争论和决策犹豫。因而对多年停滞不前，没实质进展的权威机构“不作为”行为更感郁闷，牢骚一多，就在刘所宝地吐了一地，还望见谅。希望此处的高朋能可怜我郁闷的心情，帮帮我，帮我找找实际应用中的限定性DC数据样例，多多益善——对于朋友的帮助，我们将回馈一个优秀的DC编辑系统供其本人使用。
Like or Dislike:
0 
0
[回复]
平台江 Said on 十一月 27th, 2007 at 2:02 下午 quote
关于RDF，我觉得它的本质还是一种框架，即一种元数据的容器。既是一种定型的容量，产生歧义的可能性就小。重点还得放在这个容器中的元数据的编码细节上，比如采用DC时，仍涉及到如何表达DC限定词的问题。
系统可以将最本质的元数据处理好后，很容易采用某个定型的容器进行包装。
RDF是元数据吗？这是一个问题。
Like or Dislike:
0 
0
[回复]
keven Said on 十一月 27th, 2007 at 3:03 下午 quote
RDF是一种框架容器没错，但RDF和RDFS同时是一种基于XML的语言，定义了一系列的元素和语法规则，可以看成是表达语义（甚至逻辑关系）的基础，是机读语义和实现网络资源人工智能的起点，因此不能忽视它。具体如何表达元数据的各类限定关系，当然涉及编码的最佳实践，这也是我们需要深入研讨的问题。
Like or Dislike:
0 
0
[回复]
谢涛 Said on 十一月 27th, 2007 at 7:22 下午 quote
sub-element这个称呼太好了，直白，简单，远胜于qualifier, refinement等说法。
我曾花了好长时间才逐渐弄明白原来DC谈论的修饰词，就是refinemented element。
Like or Dislike:
0 
0
[回复]
远洋过客 Said on 十一月 27th, 2007 at 11:11 下午 quote
回谢涛，在DC中的refinements本身还不是一般有等级的那种sub-elements。因为DC本身不是等级结构式的。
1. DC现在的refinements基本上是从qualifiers搬来的，以前的qualifer不能独立使用 (例如date.created, ‘created’ 当时不能独立使用）。refinements的不同之处就是它们也被认可为一种property了，因此也可以独立使用了 （例如 , ）。也就是说一个refinement虽然还是可以修饰一个元素，但也可以独立使用。 它们现在都被归到DCMI Metadata Terms这个大集合中了，与15个核心元素平起平坐。
2. 而在真正的有*等级*的元数据标准（例如几乎所有的其它标准， LOM, CDWA-lite, VRA Core4.0, PBCore, 等等）中，sub-elements必须隶属于上面的element。在做记录过程中这个等级形式很严格，数据值（values) 只能放在最‘子‘层。这是与XML的语法一致的。
但如Keven所说，有等级的结构可能会影响数据的重复使用，也可能违反1:1原则，在机器交换中产生问题。这要看哪个元数据标准做得好了。
抛砖引玉，请大家继续讨论。
Like or Dislike:
0 
0
[回复]
平台江 Said on 十一月 28th, 2007 at 8:23 上午 quote
仅从DC原则来理解——DC的原则是其立身之本，如果这个原则都有动荡性，体系也就不稳定了——我是支持远望“元素修饰词不知道是哪个英文词？Qualifier还是refinement? 不过不论是哪个，都不应该是sub-element （子元素）”的说法。
简单分析，当前alternative作为title的限定词，显然语义限定还比较宽泛。当某日，需要把这个title的限定词更加细化，那么后出现的限定词难道应该成为sub-sub-element？这种理念下，编码是不易体现的——不可能在XML中同时出现title,alternative与XXX等结构吧？如果出现了，如何体现XXX是title的限定词而非是alternative的限定词呢？
远望师“在DC中的refinements本身还不是一般有等级的那种sub-elements”的概念，是否意味着我钟情的类似编码有了更有力的支持？编码类似如下：
正题名
交替题名
从编码结构来看，正题名与交替题名是平级的——等级或从属是通过属性值来体现的。将限定词作为属性值，可以应对不同的需求扩展，更可以忽略这些限定属性，仍体现出大概念描述，这即所谓的向下兼容。
远望师也是见多识广，能否帮我寻找更多的数据应用实例供参考。我们的本意是寻找一个更合理、更官方（更权威）的数据格式作为我们首先要对付或支持的格式。当然，如果没有这些数据，只得自行确定。但确定时，能有更多专家指导，总比我们闭门造车，孤陋寡闻弄些贻笑大方的数据格式好些。
对远望师的指点，先表谢意。
Like or Dislike:
0 
0
[回复]
平台江 Said on 十一月 28th, 2007 at 8:30 上午 quote
请刘所将上面的编码格式变出来，实际效果应是：
<dc:title>正题名</dc:title>
<dc:title refinement=”alternative”>交替题名</dc:title>
另，至于采用refinement(s)还是qualifer(s)作为编码中的XML属性，由于不涉及到结构，不属我关注的重点——类似“下岗”与“失业”，我们能理解它们意思相同即可。
Like or Dislike:
0 
0
[回复]
平台江 Said on 十一月 28th, 2007 at 8:41 上午 quote
对不起，把“远洋”敲成“远望”了，请远洋师见谅。
Like or Dislike:
0 
0
[回复]
keven Said on 十一月 28th, 2007 at 10:55 上午 quote
远洋师正在丹麦开会呢！可能过两天才能看到平台江的讨论。
我可能会以这个PPT为基础写一篇论文，就DC的编码问题谈一点我的理解，不过最近很忙，看LIB20的书稿也是一件大事。现匆匆就上面的议论谈点看法。
DC属性词之间的层次关系是体现在Schema中，而不是体现在数据记录的描述中。从描述（不管是具体的XML还是RDF文档）上看，属性词完全是平面的。这就造成没有Schema就无法正确解析XML文档的问题（Schema与以前的DTD功能是一样的）。
这也就是说，目前DCMI推荐编码时独立使用修饰词，更希望采用：
<dc:alternative>交替提名</dc:alternative>而不是平台江所说的那种形式。
再谈。
Like or Dislike:
0 
0
[回复]
谢涛 Said on 十一月 29th, 2007 at 10:54 上午 quote
回复远洋过客：
在博客上短短数语发表意见，可能前后的语境不见得清楚，不过我还是尽量讲清楚。
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这样的语义表达方式笨拙，那也没有办法。不过至少，这种“初等”的表达方式，是目前软件开发技术所习惯的，虽然不高明，但是还可以用。
Like or Dislike:
0 
0
[回复]
谢涛 Said on 十一月 29th, 2007 at 11:25 上午 quote
可能是博客的局限，上文中提到江汇泉推崇的编码格式没有显现出来，这里重贴一下：
＜dc:title refinement=alternative”＞交替题名＜/dc:title＞
Like or Dislike:
0 
0
[回复]