关于KISS，曾看到一项测试，可以用来作为便捷的衡量方法：

1. 记事本测试：你能否用记事本（notepad）手工创建一条符合规范的记录，大小不超过4k？
2. 阅读测试：你能否在一小时内基本读懂规范文本？
3. 编码测试：你能否在一天内编制一个简单的客户端或服务器软件，实现简单的功能？

根据这个标准，传统图书馆自动化系统的很多东西，包括图书馆员的很多思路，都要更新换代了！

什么是完整的元数据方案？
为实现“好的元数据方案”的要求，一般而言，元数据方案应该考虑如下一些基本要素：
1、应用系统所需管理的各类数字对象的实体-关系模型（领域模型），覆盖所有元数据属性元素所描述的数字对象；
2、元数据属性元素集（数据词典），可以包括（但不限于）元素名称（作为机读唯一标识，可以URI表示，此时需要考虑命名域及维护机制）、显示名（也称为标签，中英文均可）、说明、取值（数据类型或值域，或者编码体系标准）、举例等；具体可参考DCMI元数据元素的定义方式。
3、各元素的著录规则，包括元素的推荐取值词表；
4、各类编码方式（通常有HTML, XML, RDF等）规定及实例。
目前对于数字图书馆而言，上述文档应该是一个“完整”的元数据方案所应具备的最低要求。

为什么设计一个好的元数据方案不很容易？
这主要是因为一个好的元数据方案常常需要三方面人员：IT技术人员、领域信息组织专家和用户的共同努力，合作无间才能达成。
传统的软件工程不管采用那种开发模式，都非常强调需求分析，系统设计是基于需求来做的，系统成功与否，经常把责任直接推给需求，需求是用户提的，或者最终 交由用户确认的，用户最终通常只能打碎了牙齿往肚里咽。软件工程里常说，这是因为用户的“隐性需求”没有充分挖掘，之所以“隐性需求”难以挖掘，通常有以 下三方面的原因：
1、需求无法表达：用户对于IT系统的开发全无概念，无法全面清晰地表达其需求；
2、需求没有表达：用户认为某些需求是“缺省”的，而系统设计人员并不知道；（处在不同的语境中，需求表达/理解的不一致）；
3、需求表达了没有用：用户即便把需求表达出来，由于成本、工程、效率、技术等方面的原因，设计人员也无法实现。
上述三类人员的合作，对于充分发掘系统对于语义描述的“隐性需求”具有至关重要的作用。对于隐性需求的忽视，常常是系统开发失败的主要原因。而如何挖掘“隐性需求”，往往就成为软件公司开发人员水平高低的试金石。

元数据方案设计时应考虑时的几个原则：

原则一：对于具体应用来说，元数据元素多多益善
元数据就是关于信息资源的结构化描述信息，是信息资源有序化的基础。丰富的元数据有利于信息资源的组织管理、揭示乃至数据挖掘。对于信息组织来讲，由于用户需求是复杂、多样、难以预料的，元数据永远不会嫌多，不管是描述性元数据，还是管理型元数据，总能从某个侧面反映信息资源的某些属性，总会有辅助揭示的功效。
实践中我们常常发现图书情报人员和数字图书馆用户秉持“多多益善”观点的人很多，特别是领域专家，而技术人员多认为“够用即可”。“多多益善”原则肯定会受到开发工期、成本、人员、数据可获得性等方面的限制，总会有个“度”，这里提出这个原则，主要是考虑到技术发展总是最不让人担心的事情，而应用系统的设计一旦考虑不周，就会贻害未来。

原则二：元数据应该尽可能自动产生
元数据多多益善，但并非总要人工来添加，那样成本太高，还有误差，肯定不可行。实际上已经有越来越多的元数据都是通过自动生成。例如：数码相片中的元数据有好几十项（大多是技术参数，甚至包括经纬度信息），需要人工干预的可能只有在上载或入库时添加的tag、说明信息等几项，大量的元数据都是在信息生产、加工、流转、使用等生命周期中自动生成的。
按照这个想法，数字图书馆建设的整个流程应该能够产生大量的元数据，当然这需要有一定的加工管理平台支持这种元数据的捕获。

原则三：好的元数据方案设计可以兼顾将来的需求
一个前瞻性的设计，能够为将来的发展留下伏笔，也能够反映当前系统设计人员水平。前面所述的”元数据设计”独立于系统设计是一个重要原则，能够从一定程度上保证数据的独立性，从而能够更好地保护数字资产，不会随着技术的变化而危及可获得性。元数据元素的设计应该尽可能考虑周全，但是在实际应用中可以空缺（不取值）留待将来使用。决不能因为获得困难就认为这些字段不重要。
当然”考虑将来需要”必须对信息需求进行一定的抽象才能做到，并根据相关的”实体-关系”，建立一定的应用和描述模型。管理流程不规范、多变造成信息描述的变化，可以依据模型而得到忠实的记录。

原则四：核心元素对于统一的互操作（系统集成）是至关重要的
核心元数据的意思就是大家都有的元数据属性元素，有助于实现统一的互操作，一个系统中不同的资源类型可以在核心元素的基础上，扩展不同的元素或者子元素，不应该设计或定义完全不同的”核心元素”，甚至多级的“核心元素”也是不足取的，不利于将来元数据方案的维护和数据的管理。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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