DC元数据最新报告
一般DCMI执行总裁Makx Dekkers每年要发布两次“发展报告”（Status Report应该是“状态报告”，我觉得翻成“发展报告”更吸引眼球，呵呵），国庆/中秋过后就要召开DC-2009年会了，上周新鲜出炉的发展报告，要去参会的同仁们要做点功课。
我最近多个场合说，我们在做完《我国数字图书馆标准规范研究》（一期）项目之后就基本上止步不前了，该项目固然取得了很大的成绩，但看起来并未达成初衷。首先本人需要检讨，本人的“资源集合”子项目就做得很烂（感谢张大组长给我面子，一直没有机会向您检讨，现在DC的资源集合元数据已经完全不是那个样子了，嘿嘿）。从DCMI的进展来看，后来在元数据标准规范方面最大的进步，基本上可以归结为向“机读化”的不懈努力：提出了语义互操作层次，建立了抽象模型，讨论了大量的编码规范，并探索了元数据各类功能（主要是语义功能）在机器环境中的实现机制（如linked data）。
最新的发展报告一如往常一样琐碎，撮其要点绍介如下：
1、DC元数据互操作层次“Interoperability Levels for Dublin Core Metadata”作为DCMI的推荐文件发布。该文当把DC元数据的应用（通常将应用规范称为“应用纲要”AP: Application Profile）分成四个层次：a 仅用元素名称（目前大多数应用都只到这个级别），b 把元素作为严格的“概念”（具有机器可判断的形式语义），c 不光用元素，还要包括编码模式，即在语法格式上也要严格规范，d 整个元数据记录（包括各类语义和语法的约束）都要符合规范。其中c和d都必须符合DC元数据抽象模型（DCAM）。
2、Karen Coyle和 Thomas Baker修订了《DC元数据应用纲要指南》“Guidelines for Dublin Core Application Profiles”，这可以说是当前DC元数据应用最重要的文档，我们DC元数据中文网居然没有翻译，罪过啊罪过，有没有志愿者愿意翻译的？嘿嘿。
3、Pete Johnston 和 Andy Powell辛苦修订的最终版《DC元数据XML编码规范》“Expressing Dublin Core Description Sets using XML (DC-DS-XML)” 即将公布。这个文档将使DC的XML编码完全符合DCAM。
4、Mikael Nilsson起草的《DC应用纲要描述集规范》（ Description Set Profile specification for Dublin Core application profiles）和Karen Coyle起草的《应用纲要设计模式》（“application profile design patterns” ）均可作为设计元数据实用工具和应用系统的非常好的技术文档。
5、DCMI的Diane Hillmann一直在为RDA的词表（包括FRBR实体、属性词表）建立注册系统，并试图提供符合DCAM的编码规范。一系列成果散件于一些演示文件中：
- http://www.slideshare.net/smartbroad/registering-the-rda-vocabularies-1734427
- Staff of Cambridge University Library
- Staff of the National Library of Scotland
- Libraries in the Digital Age (LIDA) conference 2009, Zadar, Croatia
6、元数据登记注册系统，在这里有一个应用可以在三个系统之间进行映射转换，似乎是一项元数据Web服务的雏形。
7、DCMI与IEEE联合教育组提出了一个应用于教育领域的元数据应用纲要草案。
Popularity: 20% [?]
Tags: DC-2009, DCAP, DCMI, 元数据Related posts
DC-Lib应用纲要错误一例
马上要召开DC-2008了，DC的邮件列表里又热闹起来。今天的一个帖子说到DC-Lib应用纲要的问题，让我想到最近有人建议尽快将DC修饰词和领域应用一并推向国标。愿望很好，但其实国内对DC元数据的应用还没有形成一种讨论的氛围，许多人都回避讨论，只想交给一些“伪精英们”（也算包括偶吧）制定出来执行就完了，其实这样是无法形成对一些问题的基本理解的，即便推出一个“正确”的国标，也恐怕会因为理解的不同而无法执行，何况对于我们来说做到“正确”是何其困难！前一阵与平台江和谢涛君的争论就很好，“我国数图标准规范研究”项目组内部不多的争论也很好，只是太少了。问题不摆到台面上公开讨论，就为以后大家阳奉阴违埋下伏笔，这是对标准化事业最大的伤害。
问题是这样的：在DC图书馆应用纲要中对于“格式（Format）”的修饰词“媒体(medium)”有一段说明：
Used to specify the medium of the physical carrier of a resource. Format without an element refinement qualifier should be used to specify the electronic format of the resource, using the encoding scheme IMT. Format should be repeated if both are applicable (e.g. a PDF file on CD).
用来特指资源物理载体的媒介类型。“格式”如果不带修饰词，则应该采用IMT（即MIME的格式词——keven注）的编码体系修饰词作为取值，特指资源的电子形式。如果即有电子格式又有物理类型（例如放置于CD上的PDF文件），则应该重复著录。
这段说明完全违反了DCAM（DC元数据抽象模型）所规定的1:1原则，因此是完全错误、应该被修正的。可惜DCMI许多文档的修订工作根本就跟不上。
Andy Powell对这个问题的回答很有意思：
Firstly, dc:format is a total mess. (I guess you knew that!)
Secondly, I think the library AP gets it wrong anyway
…….
Sigh… disclaimer, I chaired the original dc:format working group and hence share some/much of the blame for the mess – but I think it was a mess way before then anyway
当然，Andy也给出了这个问题的解释：
dcterms:medium只能用于描述资源的物理形态（格式），这在抽象模型的domain-range中说得很清楚了。因此dcterms:IMT不能用于修饰dcterms:medium，只能修饰dc:format或dcterms:format。
据此，就不存在重复元素/子元素问题了（因为描述电子格式和物理格式的元素/子元素是不同的）。
Powered by ScribeFire.
Popularity: 51% [?]
Tags: DCAP, dublincore, 元数据, 应用纲要