Image via Wikipedia

借用Leon的说法，由拉狗子（Carl Lagoze）与松佩儿（Herbert Van de Sompel）两位大牛主导的OAI-ORE规范已经在10月17日发布了其第一个正式版：1.0版（怎么才1.0啊？现在好像2.0版才是正版）。这是图林人民乃至整个网络民众的一件大事。

按照 Andy的意思，这个规范绝不仅仅是把OAI的关注对象从“收割”向“复合对象”转移，而是根本的从一种”面向服务的架构“向”以资源为中心“的思想方法的转移（试想可能又应该有不少似懂非懂的文章出台了吧？他们好像刚刚强调过要从”数据为中心“转向”以服务为中心“呢！该不会有考据派来告诉我”此service非彼service“吧？一群大猩猩！），与时下SW界linked data的运动如出一辙。有了标准开放的数据格式的描述模型，各类协议就自然有了标准化的基础，数据对象基于内容的互操作就能够在更广泛的Web上达成。整个OA领域久旱逢甘霖，那些唧唧歪歪的METS、集合元数据以及各类打包规范，应该可以基于ORE而一统天下了吧？但愿这不再仅仅是一个美好愿望而已。

ORE的复合数字对象模型可以看成是数字图书馆Kahn-Wilensky模型的扩展，K/W模型定义了handle、元数据和对象数据，Warwick框架规定了K/W结构可以进行灵活的嵌套、链接，但是并没有规定怎么做，OAI-PMH只不过从宏观层面提出一个收割协议，颇为无奈地在既无资源的语义和结构规范、又无获取协议的情况下率先给具体应用指出一个应用架构。而DCMI走的又是纯语义描述的路径，其对于实现上的漠视几乎让人（如平台江之流）感到背信弃义恩断义绝，比较相关的是其DC CD AP。基于Z39.50改造而来的SRU/SRW一直不怎么景气，SOAP/REST距离太远，Cool URI以及Linked Data又太新，实际上所有的协议离开复杂资源对象的描述标准都将一筹莫展。直到……ORE出台。

目前可以看到ORE给出了一个统一的数据模型，以及通过ATOM、RDF/XML、RDFa等打包聚合，并通过HTTP实现获取的基本规定。在应用中怎么用？还需要大家积极探索才是。这里是OAI-ORE官方的邮件列表，有兴趣可以加入讨论。

Andy说ORE的0.9版到现在的1.0版有以下三方面的修订，贴在这里供参考。

• a substantial revision to the conventions for representing Resource Maps in Atom (as mentioned previously);
• some adjustments to the recommendations for using HTTP to serve Resource Maps, in order to try to align the ORE-recommended “patterns” with (a subset of) the patterns recommended in the W3C document, Cool URIs for the Semantic Web;
• a revision of the Primer

ORE的内容是极为丰富，影响是极为深远的。如果各位有这方面的研究心得，别忘了投稿过来，偶给你开开后门啊！

当然我一直对嗜利如命的企业界能够甘心公益而心存疑虑，没有几个企业家会那么伟大，把社会责任置于企业利益之上。这时候就需要国家意志发挥作用，据说“有关部门”也确实这样考虑的，但是结果如何恐怕不容乐观。我们最缺乏一套可靠的制度保障，又没有诚信机制，事情做起来往往就会远离初衷了。所以好事能不能做好，很大程度上并不是技术层面的问题，而是制度层面的。

无论如何，这件事情作为一项研究课题，还是有许多内容值得探讨的。

首先碰到的问题是”数字出版”实际上是一个非常难界定的东西。从目前网络学习与网络出版的发展态势来看，特别是Web2.0的应用迅速席卷之后，未来的”出版”形态几乎无法预知，一切传统的流程、模式、方法都正在被颠覆。我们以”控制”和”集中”为主导的思维方式不可能提供一种具有生机活力的土壤，让一切富有创造力的新的形式自然生长出来，然后再来挑选、评判、规范、发展。

那么我们只有多多采用”思想实验”，从可能的角度，站在管理者（他们是stakeholder）的立场，考虑技术问题。有时很滑稽，或者很书呆子气，但这也是不得已而为之。

要规范数字出版，首先需要定义数字出版物。如下定义抛砖引玉：

[具有出版资质的单位(出版社)]以数字（指内容）或电子媒体（指载体）形式产生和发布的，具有独立标识或者能被唯一识别的出版物。

这个定义核心部分是清楚的，但是边界很模糊。例如什么东西不算”数字出版物”，例如网页算不算？可能需要”权威部门”提供”司法解释”。

这个定义还应该进一步明确”出版社”和”出版物”两个概念，他们与元数据规范的管理和应用有关。其它的诸如”数字内容”、“电子媒体”、”独立标识”、”唯一识别”等概念都属于技术概念，定义起来很容易。

有了这样一个可资参考的定义，就元数据标准规范来说，我们就可以开展下面的工作了：

1、界定主要的数字出版物类型；什么是数字/电子图书？什么是数字/电子期刊？还有哪些其他类型？（例如课件、电子地图、游戏、软件甚至网站、资源集合等等算不算？）

2、考察元数据规范的功能需求：为什么要制订元数据方案？制订了元数据方案是不是想解决的问题都能解决？还有哪些需求是元数据方案所不能解决的，需要其它的规范（如编码规范、协议规范）来解决？

3、所涉及的数字出版物对象的各类属性分析，结合功能需求，详细考察哪些属性应该被纳入，哪些暂缓，为什么？

4、如果简单的元数据方案不敷使用，考察是否需要建立扩展机制和应用模型，以体现元数据方案一定程度上的灵活性和可扩展性。

5、是否能建立一个数字出版物的概念模型和描述模型？通过它来定义标准的书目记录以及各种转换方法。

接下去当然好考虑具体的“数字出版物格式”，这种格式最可能是一种定义的复合数字对象结构，开放地支持各种传统的与数字出版相关的文件格式（例如MS Word格式、Adobe pdf格式等），包括各类相关的国际标准格式。其开放性在于能够应用于任何开放和私有的格式，能够支持内容与表现的分离，能够提供语义的不同阶段标注以及权威控制，以及开放的存取协议描述扩展等等。（如果我们建立标准的模型，以XML/RDF形式编码，就完全可能把元数据带到各种格式中去。目前很多新的格式（或者老的格式新的版本）都包含元数据和数字对象二进制编码两个部分，例如对于电子出版物标准我们可以制订一定的指南，用于PDF、JPEG2000、MPEG7甚至网络出版媒体、流媒体等各类数字格式中去）。

以下修订笔记，记录于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，我们还是以尽可能反映最新的标准讨论成果为宜。

我们现在制定元数据方案，最大的问题还是出发点的问题：给谁用？给机器用还是给人用？

现在的元数据方法与传统的编目规则最大的不同在于，元数据方法的成果——元数据——是真正给机器读的，这个“读”与传统MARC中的Read有质的不同， MARC还是利用机器的字符处理和匹配能力，打印卡片或者显示在屏幕上给人读，而元数据的“读”是要给网络上千千万万相互“认识”或不“认识”的机器来 读，不能读错，才能最终达到检索、利用的准确性（也就是语义互操作）。

我们“数字图书馆标准规范建设”课题制定了一大堆元数据规范（基本、专门元数据规范），实际上还主要是些元素集，把这些元素集当成完整的元数据方案方案进 行培训，说简单点有些混淆视听，说严重点有些误人子弟。应该说这个标准规范建设的课题还没有结束，它的重点应该进一步明确抽象模型和应用模型（这是需要花 大力气去做的，不是靠一两个人起草文章所能完成），在此基础上制定一系列编码方案，并且开发一些验证工具和集成环境（可以授权一些公司进行研发），再进行 推广培训。

在网络环境下，不同的应用领域采用哪些元素进行描述，实际上是一个用户自己选择的过程，元数据规范不可能面面俱到，所以元数据标准只需要定义最宽泛的核心元素（领域应用也可以制定一些领域核心），然后通过复用或自定义方式扩展所需的元素。这种方法已经得到元数据界的公认。

问题是：扩展方式如何确定？元素之间的关系如何描述？如何使计算机明确地知道你描述的属性是属于某个对象的？属性如何取值？属性值之间的关系如何定义？这 些问题都属于元数据描述的抽象模型和应用模型。这些问题不解决，元数据方案是没有办法达到“机读（机器理解）”的，元数据标准规范也是无法应用的，因此也 就是没有完成的标准规范。

由于复杂的应用环境极易造成元数据著录和编码的不一致性，开发工具和集成应用环境可以：

1、尽可能降低使用门槛，消除人们理解和使用上的障碍，使最普通的 工作人员也能过做元数据标引工作；
2、确保元数据元素之间的关系、元数据描述的抽象模型和应用模型已经被编码语言和应用环境/工具“固化”在系统中了。

这 样才能确保应用中正确实施元数据标准规范，同时减少元数据标引创建和维护人员的工作量，少死一些脑细胞。