元数据设计

什么是好的元数据方案？
元数据方案是信息系统对其所管理的信息对象的各类属性所进行的规定，通常反映为数据库表的字段结构、关系、类型及取值限定。本来是信息系统设计中的一个技术性很强的工作，通常由系统设计（详细设计）人员根据需求进行具体设定。
随着Web应用的普及，兴起了各类元数据标准，以及根据这些标准制定元数据方案（领域应用）的做法，主要是希望在更大的范围内（例如整个互联网）进行信息交换、共享和重用（也就是说，企业内部的私有数据，如果没有“交换、共享、重用”的目的，就不必凑热闹搞什么元数据方案了）。这些元数据方案常常只是对信息对象属性字段的简单规定，更进一步的问题，例如：元数据方案的目的是什么，如何用，如何保证可交换性（互操作性）等，只能依靠开发人员理解和悟性，并无定论。因此元数据方案有好有坏，依据一定的元数据方案所开发的系统，也有水平高低之分。
根据目前对于元数据的研究，以及一些语义网应用的经验，一般认为：好的元数据方案应该是信息系统内容架构的总体说明，独立于信息系统系统软硬件架构，与系统实现无关，是组织信息内容的一套独立的语义架构。这种做法在很大 程度上使信息资源内容不会因为技术进步而造成迁移上的困难，有利于信息内容的生命周期独立于信息技术的生命周期，并有助于信息资源内容的永久保存和重用。
因此我们认为，一个好的元数据方案应该具有一定的独立性、完整性、前瞻性和可操作性。

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

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

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

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

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

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

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