关于DC元数据的XML模式
江汇泉老师在我的上一篇帖子中留了一个关于DC元数据XML模式的深度讨论，非常好的一个帖子，不知为什么被列入了“待审核”评论中，所以今天才得以“解放”，抱歉一个。后面谢涛老师的系列讨论，思路清晰，论述精彩，强烈推荐！因此给予“特殊待遇”，单列此帖。（顺便一说：本人的这个博客可以自由注册，如果需要单独展开议题，注册后应该即可发帖，如有问题请留言或发email。）
看完几位老师的留言，除了下面拉拉杂杂的留言之外，希望大家能够多关注并仔细领会DC元数据抽象模型，以及基于这个模型的新的编码规范的讨论（参见Expressing Dublin Core metadata using XML，以及DCMI Architecture Wiki）。同时希望共同探讨：独立与信息系统的、基于RDF/OWL描述的“语义层”是否有可能单独建立，从而使得应用系统的功能实现（如检索、浏览等）与内容描述完全分离？
江老师的原帖如下（同样，粗斜体为我的评论）：
Read the rest of this entry »
近期关于元数据编码的讨论
警告：慎入！这个帖子会很长，主要涉及元数据编码细节的讨论。
承蒙谢涛和江汇泉两位技术大拿与远洋老师在我的博客上发起了热烈的讨论，所涉及的问题实在是在实践中非常重要，却很难武断地进行“推荐”。这里只能就我对DCMI编码的理解，夹叙加议，谈一点看法，希望国内这个领域的有识之士，例如参加过张晓林大组长标准规范课题的（像Leon、郑锡惠、徐周亚），以及CALIS国科图清华北大中科院等做过实践的，参与讨论。
本想在http://www.dublincore.cn/上讨论，但那是一个wiki，格式上不方便，这里讨论的结果将放到那边汇总。
需要说明的是，目前的“DC元数据XML编码指南”正在修订更新，将推出一个完全符合DCAM的规范，进行中情况请参见Expressing Dublin Core metadata using XML，以及DCMI Architecture Wiki 中的讨论(那里有大量的例子)。
摘要：
1、目前DCMI推荐的所有编码方案，均是尽可能遵循DCMI元数据抽象模型(DCAM)，DCAM是独立于编码、却为编码提供统一方案的数据模型。
2、目前争议的焦点实际上在于对这个模型没有透彻理解，以及对于基于XML、进而RDF的数据模型没有透彻理解。
3、XML的数据封装不能脱离XML模式（XML Schema或XMLS）或者DTD，也就是说所有包含XML实例序列化的数据原则上都需要XMLS或DTD才能让计算机读懂。而目前我们XML举例时通常直白地直接列出元素，似乎无需XMLS进行元素及结构的解析。这是不严格的。
4、因此DC元数据的XML表达（包括RDF表达）从数据上看起来是平面的，但是其结构和语义是用XMLS来约束的（如果是RDF，扩展的元素用RDF Schema进行定义），因此不能认为它是平面的。
5、这也就是说，DC元数据的形式化描述中，dc:alternative看起来与dc:title处于一样的地位，但实际上是完全不一样的，在XML文件的根元素指向格式解析模式中（通常是一个形式化的元数据应用纲要），可以明确它们的上下位关系，通常在如下的文件中规定格式：
<xsi:schemaLocation=”http://example.org/mydiglibapp/ http://example.org/mydiglibapp/schema.xsd”>6、应用系统在实现功能时，不应脱离XMLS去读XML文件。
7、拼音的编码方法：按照以前的做法（目前并不推荐），可采用修饰词的方式在XML中编码，如<title.transcription>bo po mo fo</title.transcription>。Akira在文章中给出了抽象模型的表示：
Statement (
PropertyURI(dc:title)
ValueString(汉字表示)
)
Statement(
PropertyURI(dc:title)
ValueString(Bo Po Mo Fo)
)
……根据目前DCMI同行的做法，我猜想应该采用重复元素（字段），对属性值扩展Scheme词表的形式来说明，如扩展书写方式scheme为包含pinyin, hana, hanja, kanji…等编码的词表：<dc:title Scheme=”yournamespece:pinyin”>Bo Po Mo Fo</dc:title>（如果词表有名称并需要标注的话，则编码稍微复杂些）。在正在酝酿的新推荐方案中，规定了封装的容器，弄得很复杂。
8、RDF编码的意义（完成中…）。
以上是我的理解和解释的大概。
以下是谢涛和江汇泉两位老师在我上一个帖子后的留言，干脆移到这里，并加上我的粗斜体议论（不断增加中）。（由于原文中许多代码含有<和>，拷贝粘贴时被浏览器吃掉了，我这里恢复的不一定正确，如有误请更正）
江老师留言1：
Read the rest of this entry »
演讲：元数据抽象模型与新加坡框架
讲这个主题，因为感到有必要，似乎大家都知道，但是理解各不相同。
没有自己的东西，纯粹介绍。也不一定正确，仅供参考。
说明Update：可能slideshare在某些网络以及用某些浏览器无法访问（感谢远洋老师等提供信息），在这里提供ppt下载。
| View | Upload your own
近期关于元数据的一些讨论
我没能完全理解，但就我的理解发表了一些理解：
1、元数据元素集是描述资源各个方面的属性词表；
2、元数据取值如果规定只能从某些词表中选取，这些词表就属于受控的规范词表；这属于元素取值的domain和range；
3、元数据应用纲要是为了领域应用而制订的元数据方案的一种表达形式，目前正在成为规范的，叫做“DC元数据应用纲要”，核心是符合DC抽象模型的元数据形式化表述（也就是一种机读形式），通常可以以RDF形式表达；
4、应用模型（规定应用领域的各类实体及其相互关系）、著录规则等文档，也可以成为元数据应用纲要的组成部分；
5、元数据注册系统可以作为元数据元素的命名域管理体系而存在，但命名域并非一定需要注册系统进行管理；
6、元数据元素词表，包括规定元数据取值的规范词表，都可以看成是一种人工语言，每个术语都应该被赋予唯一的URI，都可以通过注册系统进行管理；
7、元数据形式化的表达必须采用基于XML的RDF或OWL等的Schema，著录工作单当然可以通过完整表达元数据方案各种关系和约束的schema来自动生成，并进行校验。当然这需要一定的环境和软件工具来实现；
……
至于这几种元数据标准的分类，感觉在概念上有交叉，是从应用角度来分类，并不具有严格的意义。
前两天针对图林茶的困惑，也发表了一些看法（问题的陈述只是大致）：
问题1：目前针对具体应用领域制订的元数据方案，其描述对象究竟为何？
1a、任何具体的元数据方案所描述的实体，都可能是一个复合的实体，并在整个生命周期中具有不同的表现。完善的元数据方案应该首先有一个应用模型（如FRBR）进行清晰的表达，这样才有可能使得具体的描述符合1:1原则。
1b、应用系统在具体开发实现的时候，可能无法保证模型关系的完整体现，这已经在元数据方案所能考虑的范围之外了。好的实现，应该能够以较少的代价（例如一条记录），反应更多的内容（例如两种实体之间的关系）。
问题2：元数据方案不都是“描述”资源的吗？
2、元数据就是关于数据相关属性的描述，虽然有描述性元数据、结构性元数据、管理性元数据等说法，这里的“描述”取了狭义的“内容描述”的含义。纯粹玩弄词藻，就不多言了。然而属性的取舍是元数据方案的关键，不“困惑”这个，制定元数据方案就基本上没有可以困惑的了。
问题3：元数据的“元素”与XML的“元素”，究竟是不是一回事？
3、不要把元数据元素和XML中的元素混为一谈，虽然前者可以用为后者，当然，也可应用为后者的“属性”，这是编码的问题。元素与修饰词在元数据方案中都 是“术语”，都应该慎重，作为一种“元数据应用纲要”来说，复用原则是第一位的，自己添加的术语需要明确定义，并给出命名域（作为课题来说，要给出建 议），否则方案就是不完整的。
细究下去，还有许多进一步的理解，希望这次到深圳参加数图十年会议，能有机会能跟大家沟通一下，并得到大家的批评指正。
DC元素的中文翻译
最近参加了汪东波老师主持、业界许多知名单位派代表参加的“DC元数据元素集国标项目”，顺便把我们经营了多年的“DC中文网”（改版前在这里）更新一下。最主要的工作是对DCMES (Dublin Core Metadata Element Set，即DC的非限定版)的ISO和NISO版本，以及几个中文翻译版进行比较，记了一些笔记。发布在这里，以期引起更多人的讨论和批评指正，并供大家参考引用。
以下修订笔记，记录于2007年10月21日，作为备忘，并供讨论参考。
1、建立了各元素单独的参考编辑页面以便逐个进行讨论修订。同时也建立了一个15个元素的汇总页面。
2、外链的标准规范文档需要在本地做镜像，以备网络或其他问题引起查考不便。
3、《都柏林核心元数据元素集(1.1版)》最新的中文翻译文档与原文档(2006年12月18日)在元素的说明体例上并不完全一致，因为当时中文版网站缺乏版本管理（没有用Wiki）而保留了部分原有的体例（例如“术语类型”、“状态”和“发布日期”等）。
4、ISO和NISO标准和中科院基本元数据项目对于元素的排列都是按照重要性（title, creator…），而DCMI是按照字顺(contributor, coverage…)，我们也将参照ISO、NISO的顺序对元素进行排列，而不是以字顺排列。
5、目前DCMI定义元素时，名称(Element Name)作为元素的标识(id)，是给机器读的。而标签(Label)是给人读的。因此前者都用小写，后者首字母用大写。目前修订过的ANSI/NISO Z39.85:2007和IETF RFC 5013都是这样，而中科院项目是把名称也翻译成了汉语，标签保留首字母可以大写。ISO 15836:2003还是名称和标签首字母都大写。
6、目前的文本在元素的定义和内容上尽可能与经过审核的最新的ANSI/NISO Z39.85:2007、IETF RFC 5013和Dublin Core Metadata Element Set, Version 1.1保持一致（经过核对，这三者是完全一致的）。DCMI中文网的文字上有与上述文档不一致的地方。
7、DCMES在修订过程中（如NISO Z39.85:2007），对于注释进行了简化，特别去除了具体的实例（例如identifier去掉了URI、DOI、ISBN举例）。考虑到GB需要添加实例，某些简化掉的内容可以添加到实例中。
8、由于目前在文本方面尽可能参考/采用新版的DCMES,有一些地方与ISO 15836:2003不尽一致，是否合适，需要项目组集体讨论。本人建议，因为ISO 15836:2003也即将面临Review，我们还是以尽可能反映最新的标准讨论成果为宜。