电子系统实施中元数据方案制作

【前言】电子系统实施中元数据方案制作由文秘帮小编整理而成，但愿对你的学习工作带来帮助。1.3元数据标准的实施问题 随着诸多标准规范的出台，文件形成单位和保存单位如何贯彻实施有关标准，在相关系统中产生、管理和利用元数据，日益成为关系到系统建设质量乃至最终文件管理状况的关键。本文所指元数据方案（metadataschema），是文件形成单位或保存单位对电...

1研究背景

1.1国际范围内元数据标准颁布情况

作为描述文件（records）背景、内容、结构及其管理过程的数据，元数据（metadata）对于文件（包括档案）管理的重要性已经获得了广泛的认同。上个世纪末以来，澳大利亚［1］、英国［2］、加拿大［3］等国家纷纷推出了不同适用范围、使用目的的文件管理元数据标准；而相关国际标准的颁布，与各国、地方的标准形成良性的互动，［4］推动元数据标准不断走向成熟。ISO14721:2003《空间数据与信息移交系统———开放档案信息系统（OAIS）参考模型》的，引发了数字保存（digitalpreservation）领域基于OAIS的信息模型开发元数据方案的热潮。在文件管理元数据（recordkeepingmetadata，recordsman－agementmetadata）标准缺失的情况下，也有一些档案部门据此模型开展了元数据标准的探索和实践。［5］ISO23081-1:2006《信息与文献———文件管理流程———文件元数据———原则》和ISO/TR23081-2:2007《信息与文献———文件管理流程———文件元数据———概念与实施》［6］则开辟了面向文件形成机构文件管理元数据标准的疆土，其提出的多实体、多属性的元数据框架结构，则被此后很多国家、地区、单位制定的文件管理元数据标准、方案所采纳。文件管理元数据和长期保存元数据的区别和联系也日益为大家所重视。［7］ISO/TR23081-3：2011《信息与文献———文件管理流程———文件元数据———自我评价方法》则进一步明确了评价现有文件管理元数据的方法。国际上对于文件管理元数据的探索焦点从原则、概念逐步走向实施、应用。

1.2我国电子文件元数据标准的建设

2002年底，青岛市档案局颁布的规范性文件《青岛市电子文件归档与管理规范（试行）》以“附录A电子文件著录项目”的方式规定了电子文件的元数据项目；2005年底，天津市档案局制定了《天津市电子公文元数据表》；2008年3月，我国核行业标准《核电电子文件元数据》（EJ/T1224-2008）颁布；同年7月，广州市地方技术规范《电子文件档案资源管理规范第4部分：元数据》（DBJ440100/T10.4—2008）出台；2009年底，档案行业标准《文书类电子文件元数据方案》（DA/T46-2009）问世；2011年1月，ISO23081-1《信息与文献———文件管理流程———文件元数据———原则》被正式采纳为国家标准，标准号为GB/T26163.1-2010；国家档案局承担的国家标准《通用电子文件元数据规范》研究项目正在推进过程中，建设、石油等行业的电子文件元数据标准正在酝酿出台。这些行动标志着我国电子文件的元数据管理从自由探索步入了标准引导、从地方规范和行业规范走向国家规范的发展阶段，且标准的内容和形式也不断与国际标准接轨。［8］

1.3元数据标准的实施问题

随着诸多标准规范的出台，文件形成单位和保存单位如何贯彻实施有关标准，在相关系统中产生、管理和利用元数据，日益成为关系到系统建设质量乃至最终文件管理状况的关键。本文所指元数据方案（metadataschema），是文件形成单位或保存单位对电子文件元数据元素语义、语法、赋值及其相互关系（结构）的系统性规定。本文根据电子文件元数据形成和积累的规律，结合杭州市电子文件中心建设的实例，围绕着一类单位———文件形成单位在建设一类系统———电子文件管理系统（ElectronicRecordsManagementSystem，ERMS）过程中的元数据方案设计问题展开探讨。

2电子文件元数据形成、积累的规律

电子文件的元数据随着文件形成和管理过程而不断产生、累积，而这样的产生、累积是要通过系统实现的。探究元数据形成、积累的规律，首先要辨析电子文件生命周期中的系统类型。

2.1电子文件生命周期中的系统类型

从系统的功能来看，电子文件整个生命周期中的系统通常包括三类：［9］支持文件形成单位日常业务工作的开展，在此过程中形成合格、完整的电子文件的“业务系统”（BusinessSystem，BS）；［10］从业务系统中将信息以文件的方式加以捕获、维护、利用和处置的ERMS，捕获和处置分别是该系统文件管理功能的起点和终点，我们也可以将ERMS理解为立档单位档案辅助管理系统在数字世界中的功能拓展；长期保管各类电子文件，保证其真实、准确、可理解的“文件保存系统”（RecordsPreservationSystem），国际上也将此类系统归入“可信任数字仓储”（TrustedDigitalRepository，TDR）。

2.2元数据在各类系统中形成、积累的过程

电子文件不同生命阶段的元数据依次在BS，ERMS，TDR中形成，前一阶段形成的关键元数据将随着文件一起进入下一个系统。但是，不同系统管理文件的目的不同，管理成本亦有限，不可能也不需要将所有的元数据都保留下来。也就是说，电子文件的元数据是动态增加的，但并非所有的元数据都会和文件同步积累、转移，某些元数据只存在于产生它的系统中，不会进入下一个系统。当一份文件从BS进入ERMS，或者ERMS进入TDR的时候，部分元数据会与之同行，部分则会与之分离，这样的过程如图1所示。

2.3电子文件元数据的运动规律

通过图1可以看出，电子文件元数据的行程好比一条不断汇聚的河流，沿途会消耗掉一部分水分，同时也不断有新的河水注入其中。总体来说，这是一个细水长流、日积月累的过程。就在这个平缓向前的过程中，尤其是在ERMS和TDR的运转过程中，可能因为文件管理的某种需要临时性地增加元数据。这样的需要至少包含两种情况：第一，移交的需要，为便于TDR长期保存文件，ERMS在向TDR移交文件的时候可能需要临时增加元数据。比如全宗名、全宗号原本只是全宗级的元数据，文件级元数据可不包含此项，在移交时为了让每份文件具有自我说明的能力，需要给每份文件重复记录同样的全宗名、全宗号。再如为TDR制定并实施合理的文件保存规划，可能需要大量补充电子文件的技术环境元数据，除了文件格式外，还注明软件产品、版本号、压缩类型，字符编码方案、软件商信息等。第二，利用的需要，为更好地实现信息服务、知识挖掘等，可以通过元数据自动抽取工具临时挖掘文件的主题信息，并加以标注。应需临时增加的部分，通常借助特定的插件、工具完成。正如ISO23081-2:2009所言：“优质的元数据体系是动态的，能够在必要时随时增加文件管理元数据”。［11］因此，我们认为电子文件元数据具备持续形成、选择积累、应需增加的特点。

3ERMS元数据方案设计的准备

为设计出适用的元数据方案，除了人员、资金等方面的准备之外，还需要明确ERMS的系统功能定位，了解相关标准及其实施路径，掌握ERMS元数据方案设计的内容和方法，以便最终逐一确定元数据元素及其规则。

3.1系统功能定位的确定

上述BS，ERMS，TDR只是概念划分的结果，各单位需要购置的系统既可能与之对应，也可能具备其中一类系统的部分功能，或者其中两类系统的全部或部分功能，需要根据系统实际的功能定位来制定元数据方案。比如西方国家所称的ElectronicDocuments&RecordsManagementSystem（EDRMS）即为一类从电子邮件系统、桌面办公软件、工作流系统、扫描系统等办公类系统中捕获非结构化文档，并实施集中存储、统一利用和文件管理（档案化管理）的系统，有些EDRMS本身也提供工作流、扫描等功能。提供工作流并支持文件形成业务的EDRMS元数据方案，通常要单纯的ERMS包含更多的业务类元数据。类似地，如果我国有单位要实现OA系统和档案管理系统相集成的电子公文一体化管理系统，或者工程项目文档协作系统和档案管理系统相集成的项目文件管理系统，也要设计更为丰富的业务类元数据。此外，一些大型企业面临建设ERMS和TDR的双重任务，在系统选型的时候，也倾向于将两者集成在一起，对此类系统的元数据方案，则要在文件管理元数据之余，更多地考虑长期保存元数据。本文以独立的ERMS实施为假设前提展开讨论。

3.2标准环境

任何单位在设计ERMS元数据方案的时候，都要寻求标准的支持。虽然我国已经出台不少相关元数据标准，不过，标准实施还是面临两个方面的困难：

3.2.1标准适用性不够

早期出台的电子公文元数据规范在适用范围上规定得很明确，区分了文件形成单位和文件保存单位的需要，比如《青岛市电子文件归档与管理规范（试行）》明确指出面向青岛市市直机关、团体和其他社会组织等文件形成单位，《天津市电子公文元数据表》分别对电子政务系统归档电子文件和档案室向档案馆移交的电子文件的元数据加以规定，后者比前者多出5个元数据元素，同时还有各自配套的数据结构规范。但是这些标准大多为经验性总结，缺乏元数据顶层框架的支持，在与文件形成系统的互操作性方面的支持力稍弱。2008年之后出台的《电子文件档案资源管理规范第4部分：元数据》（DBJ440100/T10.4—2008）和《文书类电子文件元数据方案》（DA/T46-2009）则分别依据OAIS和ISO23081的概念模型，元数据元素的设计相对严谨，但是其内容较全面，同时包含文件管理元数据和长期保存元数据，适用范围较广，同时面向文件形成单位和文件保存单位，导致这两种具有不同文件管理职责的单位，面临实施同一个标准的境况，这就需要其根据各自的功能目标加以选择、拓展、改造、具体化的实际问题。

3.2.2标准实施支持力度不够

从国际范围的实践经验来看，ERMS元数据标准实施路径有两种：第一，将系统功能要求标准和元数据标准衔接，通过系统测试的方式强化合规性要求，使得元数据标准由书面的规定变成市场通用软件内嵌的事实标准。这样的系统功能要求标准包括：1997年开始颁布、并且每隔5年更新一次美国国防部标准DoD5015.2-STD《文件管理软件设计标准》，其中具体规定了文件、文件夹的元数据；［12］2002年英国公共文件局推出的《电子文件管理系统功能要求》系列标准，元数据标准是其中第2部分；欧盟《文件系统通用要求》（MoReq）的2008年版本MoReq2，元数据方案是其重要的一个附录［13］；在MoReq2基础上推出的改进版本MoReq2010，则将元数据方案和功能要求条款密切融合，即在功能要求条款中明确具体的元数据要求。［14］第二，制定元数据标准的实施指南，指导各单位具体应用。比如加拿大国家图书与档案馆（LAC）在颁布《加拿大政府文件元数据标准》的同时，颁布了《加拿大政府文件元数据应用方案》，阐明了元数据元素的应用规则和方法。［15］据笔者了解，已经完成起草任务的我国《电子文件管理系统通用功能要求规范》和《通用电子文件元数据规范》以及《文书类电子文件元数据方案》（DA/T46-2009）相对独立；亦未见有关文件元数据标准的实施指南。作为文件形成单位，应该牢牢立足于文件形成单位ERMS的基本定位及其元数据的构成特点参考既有标准。鉴于ISO23081提出的元数据模型以及实施建议已经成为国际最佳实践经验，本文将此标准为基础展开探讨。

3.3ERMS元数据方案设计的技术路线设计

ERMS元数据方案，就是选择元数据元素并建立其相互关系。根据ISO23081-2:2009的规定，元数据元素的选择路径是有基本规律可循的，那就是基于文件、责任主体、业务、法规、关系等五类实体的文件管理元数据模型，依次定义和标识实体及其级次；按照标识、描述、使用、事件计划、事件历史、关系等六类属性的模块化设计思路，描述实体及其级次所必须的元数据，建立相关实体/级次元数据之间的关系；［16］根据ERMS需要管理的文件的特点，以及系统实施单位业务和文件管理的情况，建立元数据赋值规则（如赋值范围、赋值格式、赋值方式等），建立元数据管理规则（如存取权限、导出格式）等。一个元数据方案，只有具体定义到每个元数据何时由谁如何产生、修改、利用、删除的程度，方可实施。本文主要聚焦于实体、实体级次及其相互关系的确定上，这是元数据方案设计的根基。

4实体的确定

4.1基本实体模型

ISO23081：2009确定的元数据模型，包含文件、责任主体、业务、法规、关系等五大实体，如图2所示，这是ERMS实体实施的顶层框架。［17］其中的业务实体分为形成文件的业务和文件管理业务两部分，这进一步印证了本文图1所揭示的元数据形成和积累的过程。区分实体的意义在于准确定位元数据描述的对象，理解构成文件管理整体环境的各要素及其相互关系。通过分实体的元数据描述，有助于实现系统功能的模块化设计，以及跨系统的互操作。

4.2实体的实施方式

ISO23081标准申明并不要求直接实施五大实体，而是可以采取非常灵活的策略，既可以选取其中的一种或多种实体，也可以在上述五大实体之外，扩展新的实体。实体的实施方式取决于不同实体描述保持持续链接的能力，也和系统功能的实现方式有关。具体说来，主要包括以下几种实施方式：

4.2.1单实体实施

采用以“文件为中心”的实施方式“简化”实体模型，即在文件实体中包含了其它实体的信息。早期时候出台的元数据标准多采用这种模式，如1999年1.0版的澳大利亚联邦政府机关文件保管元数据标准。早期的档案辅助管理系统也多采用这种实施方式。

4.2.2多实体直接实施

在文件、责任主体、业务、法规、关系实体中选择2-5种实体实施。比如我国《文书类电子文件元数据方案》（DA/T46-2009）采用了文件、责任主体、业务和关系4类实体；MoReq2将文件保管期限与处置表理解为特定的法规标准，采用了文件、文件保管期限与处置表（法规标准）、责任主体三类实体，而业务、关系实体则作为其他实体的属性。［18］

4.2.3多实体扩展实施

即除了文件、责任主体、业务、法规、关系这五大实体之外，还拓展应用其他实体类型。文件、责任主体、业务、法规这四个实体都是多层级的，每个层级都可能包括标识、描述、使用、事件计划、事件历史、关系等六个方面的属性元数据，而且实体的元数据本身还要靠元数据来描述，如此形成多实体、多层次、多属性的循环、关联，由此可以将实体层级、属性、元数据定义等也作为实体来实施。MoReq2010是多实体扩展实施的典范，其规定已经细致到可以在系统中直接应用的程度。MoReq2010共定义了文件聚合（aggregation）、类（class）、组件（component）、背景元数据元素定义（ContextualMetadataElementDefinition）、处置保留（DisposalHold）、保管期限与处置表（DisposalSchedule）、实体类型（EntityType）、事件（Event）、功能定义（FunctionDefinition）、组（Group）、元数据元素定义（MetadataElementDefinition）、文件（Record）、角色（Role）、服务（Service）、模板（Tem－plate）、用户（User）共16个实体类型。［19］这16个实体类型大致可以分为六类，如表1所示。其中聚合、类别、文件、组件属于文件实体的不同层级，处置保留、保管期限与处置表属于法规标准实体的三个具体类型，组、角色、用户属于责任主体实体的不同层级；其余8个实体类型分别从属性、元数据定义（元数据的元数据）、系统这三个角度作的拓展：事件乃属性元数据实体，背景元数据元素定义、元数据元素定义、模板、实体类型属于元数据定义实体，而功能定义、服务这两个实体类型属于ERMS系统本身的元数据。

4.3杭州市电子文件中心

ERMS的元数据实体杭州市电子文件中心项目是由杭州市档案局承担的系统建设项目，其主要任务是为杭州市党政机关统一建设ERMS，即在全市范围统一采购、部署和维护ERMS，杭州市档案局为各ERMS使用单位提供基础设施、系统平台和应用软件的服务，但不代替其完成本单位内部的文件管理业务。这也是我国地方政府电子文件中心建设的一种新定位，不同于永久保管文件、文件中转站、现行文件查询服务、文件备份等其他各地电子文件中心的功能定位。［20］该项目计划分四期开展，一期已经于2010年完成，实现了杭州市政府机关统一使用的办公自动化系统（OA）的元数据改造，使其产生合乎文件管理要求的元数据；二期于2011年10月完成，完成了ERMS的选型、研发和试点，可以接收管理OA中的电子文件；三、四期的建设将逐步扩大ERMS的使用范围，逐步和其他系统衔接，以捕获更多类型的电子文件。本文简单介绍二期项目设计完成的元数据方案。杭州市电子文件中心ERMS的元数据方案采用多实体实施模式，包含文件、责任主体、文件形成业务、保管与处置、权限管理五大实体。其中保管与处置、权限管理属于法规标准类的实体。文件实体处于核心地位，与其他实体相互链接。关系实体作为文件实体的属性加以实施。本项目并未采用完整的业务实体，仅将文件形成业务作为一个实体，这跟整个系统的实施方式有关。描述文件形成业务，即收发文处理过程的业务元数据，并非在ERMS中产生，而是在OA中产生、被ERMS接收管理。这些元数据在OA中被固化为一个XML文档，作为文件的有机组成（可以视为文件的一个特殊的组件———笔者注）随同文件内容一起进入ERMS。这个XML文档相对独立，目前暂不进入文件元数据库中，日后若普遍存在查询文件形成业务数据的需要，可比较方便地将其中元数据导入文件元数据库中。至于文件进入ERMS之后产生的文件管理业务元数据，则作为文件实体的一个属性存在，其中大多被包括在“事件历史元数据”中。本项目借鉴了MoReq2和MoReq2010，将保管与处置作为独立实体加以实施，系统将将该实体中包含的保管期限、ERMS保存期限、触发条件、处置行为等元数据作为一组相互关联的元素加以实施，定义好的保管与处置规则可直接应用在类、案卷或文件上。权限管理实体实施的思路与此类似。

5实体级次的确定

5.1实体的级次

ISO23081的概念模型中，文件、责任主体、法规标准、业务等4个实体都具有多个层次，其中文件实体涉及全宗、系列、案卷、文件等层级，责任主体实体包括机构、部门、工作组、个人等层级，业务实体包括联合职能、职能、活动、事务等层级，法规标准实体包括法律、政策、业务规则等层级。区分层级的意义在于精确地定义各层次的元数据，同一实体不同层级的元数据，既有相同的部分，也有不同的部分。而对于每个层级都有的元数据，下位层次则可以通过链接继承上位层级实体的元数据，而不一定要全部重复描述，这可以在一定程度上精简元数据方案及其实施成本。

5.2文件实体级次模型及其实施

文件实体是各种实体实施方式中必备的实体类型，因此在各种层次体系中，文件实体的层级最为关键。笔者综合考察了MoReq2，MoReq2010，I－CAREQ以及我国标准《电子文件管理系统通用功能要求》研究成果中所规定的信息模型，构建了如图3所示的文件实体级次模型，该模型包括聚合（aggregation）、文件（record）、组件（component）三个层次。聚合是由文件组成的，文件是由组件组成的。这三个级次是任何一个ERMS元数据方案都要描述的对象，缺一不可。

5.2.1聚合

聚合即按照机构职能、业务或者文件的性质形成的文件集合体。在ERMS中，聚合通常表现为文件夹（folder）的形式，也可以表现为文件类型（recordstype）的形式。按照档案管理的传统，聚合又可以细分为三个层次：全宗、类目和案卷。其中，全宗（fond）是最高的文件聚合层次，在ERMS中，它表现为根文件夹（rootfolder）。类目（class）一般指全宗下具有有机联系的文件集合体，在传统意义上的档案分类体系中，类目的设定一般比较稳定。类目可以有多级，在ERMS中，可以建立多个父文件夹（parentfolder）和子文件夹（childfolder）；也可以根据多个维度建立不同的类目结构。案卷（file）是最低的文件聚合层次，可以在类目下根据需要灵活地增加案卷。在ERMS元数据方案中，既可以将全宗、类目和案卷设定为聚合（文件夹）这一个级次，也可以区分为全宗（根文件夹）、聚合（子文件夹）这两个层次，或者保留全宗（根文件夹）、类目（中间层次文件夹）、案卷（最低层次文件夹）这三个级次。一个实体级次的好处是系统设计更为简单、统一；三个实体级次的好处在于更便于区别化对待不同的聚合层次，比如不同级次聚合的编号规则不同，且与档案管理传统有效衔接；两个实体级次则综合了一个实体级次和三个实体级次的好处。值得一提的是，在MoReq2010的实体模型中，对等使用了聚合、类两个实体级次，前者指文件系统中的文件夹，通常是为了文件形成者对文件归类而设置；后者则是指产生于同一业务活动因而具有相同保管期限的文件集合，通常是为了文件管理员（可以理解为文件形成单位的档案管理员）鉴定处置文件而设置。在实际单位，聚合和类可能一致，也可能不一致。这样的设置照顾到了有些单位分类方案和保管期限表不衔接的情况。

5.2.2文件

文件是能够独立记录业务活动过程和结果的信息对象。文件是文件管理业务意义上而非技术意义上的最小单元。在数字环境中，文件本身可以被理解为一个容器，其中可能包含一个或多个组件（component）。包含单个组件的文件为单文件（singlerecord），包含多个组件的情况则又两种：第一，组成文件的组件之间具有技术上的紧密关联，如网页文件中的HTML、CSS、JPEG图片，或一份嵌入外部音频、视频的年度报告等，它们共同构成一份复合文件（compoundrecord）。第二，组成文件的组件之间具有管理意义上的紧密关联，如请示和批复是两个相对独立的文档，但二者需要组合在一起才能表示一个完整的管理活动，这样的文件被称为组合文件（combinedrecord）。只有理解了复合文件和组合文件的存在，我们才能够充分认识到ERMS管理到组件级次的必要性。

5.2.3组件

组件是计算机系统中一组数字信息流，是技术意义上的最小管理单元，如一个图片，一个word文档，数据库的一个视图等。识别哪个（些）组件构成一份文件，主要看这个（些）组件能否独立地反映业务活动。组件可能有两种表现形式：单组件和复合组件，后者本身是有多个技术上紧密关联的组件组成。比如就一个问题产生的一问一答两封电子邮件共同构成一个组合文件，其中一封电子邮件带着附件，这封邮件及其附件共同构成复合组件。对于以非结构化形式存在的组件，IT领域也称之为文档（document）。

5.3杭州市电子文件中心

ERMS的元数据实体级次杭州市电子文件中心ERMS的元数据方案中，文件实体包含全宗、类、案卷、文件、组件五个级次；责任主体实体包含单位、部门、角色、人员四个级次，其中角色是一定数量操作权限的集合，部门可以按需改变，人员也可以流动，而角色是相对稳定的；文件形成业务实体目前只有一个级次，随着三期、四期ERMS管理对象由OA公文向行政审批系统中业务文件的扩大，该实体的级次可能增加；保管与处置包括保管与处置规范、保管与处置规则两个级次，前者描述国家档案局及相关主管部门颁布的有关电子文件保管期限和处置要求的法规规范，后者描述具体的处置规则；权限管理实体只有一个级次。

6元数据的确定

6.1元数据的模块化设计

确定了实体及其级次之后，需要确定每个实体级次的元数据元素。ISO23081—2：2009推荐采用模块化设计思路，即每个实体，尤其是文件实体，包含标识、描述、使用、事件计划、事件历史、关系等六类元数据，这样的元数据，被张正强教授称为“属性元数据”。［21］可以看出，这样的设计思路吸收借鉴了戴维?比尔曼提出的“可为业务活动接受的通信的元数据参照模式”的成果，该模式将文件管理元数据分为登记、期限和条件、结构、背景、内容、利用史六个层次。［22］

6.2属性元数据的实施

具体的ERMS项目，可根据六类属性元数据模型灵活变通，设计出可在系统中实施的元数据。比如MoReq2010将实体的属性信息区分为元数据、事件历史、权限控制列表三类，如图4所示。其实这三类信息都是元数据，只不过因为事件历史、权限控制列表（使用类属元数据）这两类元数据非常重要，MoReq将之凸显出来。因为实体是有级次的，故需要根据实体及其级次的特点，选择实施上述六类元数据的部分或全部。对于文件实体而言，这六类属性元数据都是必须的，但是实施的方式有别，不同级次同类属性元数据包含的具体元素亦有别。下面分别阐述文件实体中标识、描述、使用、事件计划、事件历史、关系元数据的一般实施要求：

6.2.1标识类元数据

此类元数据用于标识文件实体，是每个文件实体级次都必备的属性元数据，如全宗号、类号、案卷号、文件号、组件号等。

6.2.2描述类元数据

此类元数据用来描述文件的内容，以方便检索，是每个文件实体级次都必备的属性元数据。如全宗名、类名、案卷标题、文件题名、摘要、主题词等。

6.2.3使用类元数据

此类元数据用来描述和文件利用、权限有关的信息，至少可以细分为三类：技术环境、秘密程度、访问权限等。技术环境元数据描述文件的软件、硬件、格式等方面的信息，如存储格式信息、计算机文件名、计算机文件大小、完整性等。秘密程度元数据用来标识文件实体内容的保密要求，如密级、开放等级等。访问权限元数据用来记录文件利用的详细信息，一般要定义何文件能够由谁执行什么操作，通常由一组相互关联的元数据组成。虽然都属于使用类元数据，但是技术环境、秘密程度、访问权限这三类元数据的实施层次及其方式有所区别。技术环境元数据需要在最低文件实体级次———组件上精确定义，只有组件才是ERMS切实管理的内容对象，才具备存储格式信息、完整性等属性信息。其他高层次的文件实体级次则并没有此类属性信息。秘密程度元数据需要在文件、聚合级别实施，下级实体可继承上级实体的秘密程度元数据，原则上组件不具备独立的秘密程度元数据，虽然让同一文件的不同组件具备不同的秘密程度在信息系统中毫无问题，但是这样设置会增加管理的复杂度。访问权限元数据可在各个文件级次上都要实施，下级实体可继承上级实体的访问权限元数据，不过在组件级别上定义的情况较为罕见。也可以将访问权限元数据单独作为一个实体来实施，与文件实体进行链接。

6.2.计划类元数据

此类元数据用来描述文件进入ERMS后将要发生的管理行为，体现了对于电子文件管理过程的事前计划和控制，比较典型的事件包括创建、捕获、处置、调整开放程度、调整密级等。这类元数据通常包括事件时间、类型、描述等一组相互关联的元数据，可能由ERMS根据其他元数据自动产生，比如某类文件的处置计划元数据可以根据其应用的“保管期限与处置”规则自动产生。事件计划类元数据是传统档案辅助管理软件相对缺失的部分。

6.2.5事件历史类元数据

此类元数据用来描述ERMS已经发生了的管理行为，通常即执行了的事件计划。通过对电子文件管理过程的同步记录，可以支持对于ERMS管理过程的事后监督和审计。事件历史类元数据也由ERMS自动记录。6.2.6关系类元数据虽然关系也可以作为单独的实体来实施，不过目前大部分的ERMS规范和项目都是将关系作为文件实体的属性。

6.3杭州市电子文件中心

ERMS的文件实体元数据除了将使用类元数据中的访问权限元数据单独作为一个实体之外，杭州市电子文件中心ERMS的文件实体元数据包括其他所有属性元数据。此外，在设计文件实体的元数据时，还需要注意处理不同文件类型、组件类型的元数据设置问题。所谓文件类型，是指根据业务活动的需要，对若干具有共性的文件的抽象表示。文件类型可以为一个单位的分类方案所直接体现，也可能无法在分类方案中直接体现。典型的文件类型如发文、合同、工程图纸、发票、订单等，不同的文件类型在文件级次往往具备一些不同的元数据，如合同的发文的签发者，合同的甲方、乙方、合同金额等。对于这种情况，本项目设置了一个通用的文件级次元数据集，未来随着ERMS管理范围的拓展，将在此基础上再逐一明确各文件类型个性化的元数据。除了多文件类型外，ERMS还要管理不同类型的组件（即计算机意义上的文件），一般根据技术属性划分组件类型，比如文本、图片、音频、视频等，不同类型的组件的技术环境元数据（可能还包括其他属性元数据）并不相同，这类元数据也被黄玉明局长称为“编码元数据”或“技术元数据”，国内外也有很多标准支持。［23］对于这种情况，仍然可以借鉴对于不同文件类型元数据的处理方法，即先设置一个通用的组件级次元数据集，在此基础上再逐一明确各媒体类型组件个性化的元数据。

7小结

元数据是ERMS的血脉，元数据方案与其所有功能都存在关联，设计阶段需要考虑的问题复杂而细致。本文只对实体、实体关系的确定以及元数据模块化思路进行了初步的探索，未涉及到更为细致的语法、语义规则、赋值要求和系统实现方式，更未涉及多元化的元数据管理规则。在写作的过程中，笔者深觉ERMS元数据方案设计的不易，需要在实践中不断的摸索。ISO23081为ERMS元数据方案的设计提供了坚实的概念框架，国内相关标准则为ERMS元数据方案的设计提供了丰富的元素。然而，任何的标准都不可能一成不变地应用到每个单位，系统实施者需要根据系统使用单位文件及文件管理的实际情况，以及软件产品本身的基础加以变通。与此同时，任何一个具体的元数据方案本身也需要不断发展完善，在初始设计的时候，要充分考虑其日后的变化，保证方案的可持续性。

本文建立的文件实体级次模型，得益于中国人民大学钱毅副教授的启发，本文关于文件类型的定义，得到了加拿大英属哥伦比亚大学兼职教授谢丽的指点；作者在此表示感谢。