讲座预告：关于元数据的最新进展
Update：讲座时间：10月30日上午9：30-11：30。地点：上海图书馆系统网络中心3508会议室。
感谢王松林老师，让我就元数据的最新发展和对语义互操作的理解，给他的研究生介绍一下。我最近将花些时间，系统地进行一些梳理，打算于10月30日和11月20日上午进行介绍，届时也欢迎我的同事以及华师大的研究生一同参与交流（时间可能会有变动，地点也未定，如您感兴趣，请关注本博客的更新）。
10月30日的讲座大纲目前考虑包括如下十二部分内容（这是个雄心勃勃的计划，如介绍不完，将顺延至下次）：
1、DCMI组织机构的变化
自从写完那篇《DC元数据的历史、现状和发展》一文之后发生了哪些变化，为什么。
2、DC元数据应用纲要（DCAP）方面的进展
主要是两个AP的规范文档以及两个三个AP实例（其中一个是草案）。
3、DC元数据抽象模型（DCAM）
为什么及是什么
4、元数据描述的新加坡框架
为应用纲要提供理论基础，回答“一个实用的元数据方案应该包含哪些内容？各类内容的关系是什么？”的问题。
5、元数据描述集的定义（DSP：Description Set Profile）
为什么需要DSP？与应用纲要什么关系？
6、DC元数据编码
包括XHTML、XML、Text、RDF四个编码规范。
7、语义互操作层次
同一组属性集在编码和约束上的不同规定决定了互操作程度的不同，据此区分语义互操作层次。
8、部分元数据应用项目简介
主要是这两年DC年会的案例以及应用了DC元数据的项目汇总。其它不用DC元数据的项目也需要做些介绍。
9、元数据应用相关工具
包括生成工具、转换工具、映射工具、抽取工具、质量控制工具等。
10、关联数据是一种元数据
图书馆有哪些数据值得做关联数据？
11、元数据与规范控制
元数据与本体术语体系，规范控制如何实现？
12、RDA作为一种元数据方案（规范但不是格式）
哪些地方用到了/借鉴了DCMI的元数据方法论？比AACR2有什么大的变化？
Popularity: 19% [?]
Tags: DC Metadata, 元数据, 讲座Related posts
代码示例2：DCq编码实例
<?xml version=”1.0″?>
<!DOCTYPE rdf:RDF [
<!ENTITY rdfns 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
<!ENTITY rdfsns 'http://www.w3.org/2000/01/rdf-schema#'>
<!ENTITY dcns 'http://purl.org/dc/elements/1.1/'>
<!ENTITY dctermsns 'http://purl.org/dc/terms/'>
<!ENTITY dctypens 'http://purl.org/dc/dcmitype/'>
]>
Read the rest of this entry »
Popularity: 68% [?]
Tags: DC Metadata, encoding, Metadata, RDF, 元数据Related posts
关于DC元数据的XML模式
江汇泉老师在我的上一篇帖子中留了一个关于DC元数据XML模式的深度讨论，非常好的一个帖子，不知为什么被列入了“待审核”评论中，所以今天才得以“解放”，抱歉一个。后面谢涛老师的系列讨论，思路清晰，论述精彩，强烈推荐！因此给予“特殊待遇”，单列此帖。（顺便一说：本人的这个博客可以自由注册，如果需要单独展开议题，注册后应该即可发帖，如有问题请留言或发email。）
看完几位老师的留言，除了下面拉拉杂杂的留言之外，希望大家能够多关注并仔细领会DC元数据抽象模型，以及基于这个模型的新的编码规范的讨论（参见Expressing Dublin Core metadata using XML，以及DCMI Architecture Wiki）。同时希望共同探讨：独立与信息系统的、基于RDF/OWL描述的“语义层”是否有可能单独建立，从而使得应用系统的功能实现（如检索、浏览等）与内容描述完全分离？
江老师的原帖如下（同样，粗斜体为我的评论）：
Read the rest of this entry »
Popularity: 79% [?]
Tags: DC Metadata, 专业评论, 元数据, 元数据, 编码, 语义技术Related posts
近期关于元数据编码的讨论
警告：慎入！这个帖子会很长，主要涉及元数据编码细节的讨论。
承蒙谢涛和江汇泉两位技术大拿与远洋老师在我的博客上发起了热烈的讨论，所涉及的问题实在是在实践中非常重要，却很难武断地进行“推荐”。这里只能就我对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 »
Popularity: 88% [?]
Tags: DC Metadata, DCAM, 专业评论, 元数据, 元数据, 编码, 语义技术Related posts
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，我们还是以尽可能反映最新的标准讨论成果为宜。
Popularity: 100% [?]
Tags: DC, DC Metadata, Metadata, 中文翻译, 元数据, 元数据, 标准规范, 笔记, 都柏林核心元数据