DC-2011 征文通告
都柏林核心元数据应用国际会议
元数据协同：超越语言进行描述
原文参见：http://dcevents.dublincore.org/index.php/IntConf/dc-2011/schedConf/cfp
本届都柏林核心元数据年会将于2011年9月21日-23日在荷兰海牙召开。
“当今的网络环境下, 元数据正日益成为大规模分布式资源管理的核心工具。近年来,由于跨领域合作交流的驱使,原先相对孤立的元数据社区之间的联系日益密切。但元数据标准尚无法满足各类机构社团间的互操作性需求。元数据协同（Metadata Harmonization）被定义为支持多个元数据规范进行组合的互操作问题，它已成为未来网络资源元数据应用的核心问题.”［1］理解元数据应用纲要的关键在于元数据协同，虽然对于这一点人们有所了解，但是如何设计描述语言却依旧挑战巨大。DC-2011将基于不同元数据方案的交融交汇，重点探讨描述语言设计的理论和实践问题，进行探讨不同的元数据方案之间的相互融合需要解决语言的问题。
截稿及重要时间安排:
- 投稿截止:2011年4月16日
- 录用通知:2011年6月18日
- 定稿提交:2011年7月23日
大会除上述主题外，也欢迎任何其它元数据主题的论文、报告和海报等形式的投稿，如：
- 元数据制定原则、指南和最佳实践
- 元数据质量（方法、工具和实践）
- 概念模型和框架(例如，RDF，DCAM，OAIS)
- 应用纲要
- 元数据生成（方法、工具和实践）
- 跨领域、语言、时间、结构和规模的元数据互操作
- 跨领域的元数据应用（例如记录留存、永久保存、保管(curation)、机构库、出版）
- 领域元数据 (例如，企业、文化记忆机构、 教育、 政府及科研领域）
- 作为语义网词汇的书目标准（例如，RDA、FRBR、主题词表）
- 可获得性元数据
- 科学数据、e-Science和网格应用方面的元数据
- 社会化标注和元数据构建中的用户参与
- 使用情况数据（paradata/attention元数据）
- 知识组织系统(例如：本体、分类法、规范档、大众分类法和叙词表）和SKOS(简单知识组织系统)
- 本体的设计与开发
- 元数据与本体的整合
- 搜索引擎和元数据
- 关联数据和语义网（元数据及应用）
- 词汇表注册及注册服务
投稿
- 所有提交的论文、报告、挂图摘要，和社团工作组、分会场会议必须经过DCMI的同行评议系统（链接在页面底部）。
- 作者需进入同行评议系统进行注册，在“作者信息”的链接下有相关提交流程的介绍。
- .所有的投稿必须用英文撰写。
- 所有投稿都将由国际性的学术委员会进行专家评审。
出版
- 经审核通过的论文、项目报告和挂图摘要将在此次会议的官方文集上发表，见http://dcpapers.dublincore.org/ojs/pubs。
- 分会场会议和社团工作组的文摘将在在线会会议议程上发表
- 论文、研究报告和挂图摘要必须符合DCMI同行评议系统的格式模板要求。
- 若无特殊安排，被录用的论文、项目报告和挂图应该至少由其中一位作者在海牙会议上宣读。
- 为了稿件能够顺利接收与出版，所有的投稿者需提供自己的基本资料，包括目前的专业职务和联系方式等。
稿件的种类
论文（8-10 页） 论文既可以详细描述创新性的工作，也可以对前述的一些领域性重要进展或者最佳实践进行介绍评议。
论文评判标准如下：
- 实现方法的创新性
- 所做贡献的质量
- 呈现结果的重要性
- 表达的明确性
项目报告 （4-5 页） 项目报告应该简明扼要地介绍一个特定的模型、应用或者活动。 项目报告的评判标准如下：
- 技术描述的精确性和完整性
- 对其他潜在用户技术指导的可用性
- 表达的明确性
挂图 (1-2页) 挂图是关于正在进行中的项目或课题研究的展示，或者已完成项目、课题研究的最新结果的展示。挂图建议应当包括一个长为一到两页的摘要。
挂图的评判标准如下：
- 精确陈述研究项目的目标和里程碑事件
- 研究课题或者项目的重要性
- 陈述主要的难点和进一步的研究
- 陈述结果和取得的主要成果
- 表达的明确性
会议现场将会安排一个或多个分会场来展示和讨论这些挂图。在会议网站上将会有关于如何准备挂图展示的指导和说明。除非另有安排，已录用的挂图必须至少由其中一位作者在海牙会议上宣读。根据前期安排，挂图的摘要可能被收入在此次会议的论文集中，并通过4-10分钟的视频进行展示，同时根据提交挂图摘要的URL地址将该视频上传到YouTube网站。
分会场会议 & DCMI社团工作组会议 分会场会议和社团工作组会议的提案应控制在800-1200字内，并含35-50字的用于宣传会议的摘要。会议提案必须明确一下内容：
- 会议召集人
- 假如可能，请给出参与者的类型
- 会议：
- 目的
- 议程
- 活动 (包括任何技术要求)
- 周密而完善的会议日程安排（包括会后总结报告）
- 工作小组会议的提案必须明确具体的DCMI社团（请参见http://www.dublincore.org/groups/#communities）
分会场召集人在会议申请审核通过后需就会议的完善、日程安排和会议的召开与会议主席密切合作。工作组主席经与会议委员会磋商，将会审查分会场会议的提案。工作组主席与DCMI相关社团的主席或联席主席进行磋商后，可以审核社团工作组的提案。会议提案的评估标准如下：
- 内容的质量和组织结构
- 选择该格式的理由
- 调动互动和参与的方法的证据
- 参与的包容性和多样性
- 要有吸引一般参会者的可能性，对于工作组会议，则还要吸引社团的兴趣。(包括除会场以外任何必需的技术如Skype)
[1] Nilsson, Mikael. (2010). 元数据标准化从互操作到统一：为元数据的统一设计一个可发展的框架.论文.瑞典皇家理工学院计算机科学和通信专业。斯德哥尔摩，瑞典。http://kmr.nada.kth.se/papers/SemanticWeb/FromInteropToHarm-MikaelsThesis.pdf
作者指南 所有经审核通过后的论文、项目报告和挂图都将收录到DC-2010会议论文集。根据提交文档的类别确定适当的模板格式：
为了确保可读性和文面的一致性，作者应该使用模板来规范投稿格式。
每个类别稿件的最大长度和评判标准都罗列在http://dcevents.dublincore.org/index.php/IntConf/dc-2011/schedConf/cfp的论文要求中。
DCMI坚持以盲审方式进行同行评审，这样作者不知道评审者的方式。但不采用双盲审的方式，因此，评审者可以知道作者的身份。
投稿可以点击下列链接：
投稿流程第一步……
讲座预告：关于元数据的最新进展
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有什么大的变化？
代码示例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/'>
关于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 »