-
1 导言
元数据（Metadata）是关于数据的数据，即根据特定的目的定义描述规则来描述特定类型的资源，是对数据进行组织和管理的基础。随着语义网和大数据的发展，大量的各种来源的资源和数据可被存储和管理，W3C认为元数据在集成和组合来自不同源的数据方面具有重要的作用。元数据可以对任意层次的信息内容元素、信息单元和信息集合以计算机可识别和理解的方式定义、描述、指向、链接、传递和动态组织。数字信息环境下的元数据应能满足根据语义、应用和结构需要对任何信息内容（包括数据、文件、规则、过程、体制）进行定义、标记、描述、识别、验证和解释。满足信息系统对内容的指向、确认、检索和传递，并进行深入的过滤、析取、转换、链接、合并、集成和重组。
为保证信息系统中数据的一致性和互操作性，各系统建立之初的元数据规划设计需要根据一定的规则来建设，并建立开放的元数据定义、验证、解析机制，保证系统可持续发展。本指南的目的在于从基本理论和流程的角度指导和约束各个系统和各层面在设计元数据时应遵循的方法和流程。适用的使用对象包括系统分析人员、系统开发人员、元数据设计人员、数据管理人员、服务及最终用户等。
1.1 元数据的描述对象
元数据的描述对象不仅包括描述信息对象（图书、期刊文献、网络文件、图像等）的数据，也包括信息内容、信息系统、信息过程中各个层次的内容，如分类法、用户使用政策、信息服务模块或界面等。
1.2 元数据的通用技术性要求
在数字环境中讨论元数据时，对元数据的设计有下列技术性的要求：（1）开放性定义，即元数据的定义本身是公开可获取的和采用标准方式实现的，可通过标准或通用方法来识别和解析元数据所描述的信息内容。(2)开放性语义确认、验证和解析，即元数据的语义可通过标准或通用方法来识别、验证和解析。（3）可交换、可复用、可继承和可扩展，即可基于开放标准对元数据进行交换，在不同元数据集间进行元素的复用、继承和扩展。（4）计算机可识别和理解，支持计算机对元数据以及用元数据标记的信息内容进行识别和理解[1]。符合上述要求的元数据格式将能方便地应用，理解和交换，成为数字信息环境中的基础设施。
1.3 元数据技术体系
为了开放地描述和组织信息内容的各个层次及其相互关系，需要基本的方法和技术体系：（1）技术体系中最基本的内容就是编码，信息内容由ISO10646(UCS)/Unicode来编码，实现底层数据编码的一致性。（2）统一的标识符URI，各类以及各个层次的数据都有统一的唯一标识符。（3）对信息单元的内容、结构、格式等由基于XML的标记技术进行定义、标记、描述和组织。（4）设计的元数据格式在开放登记系统中登记，登记系统通过开放平台提供元数据格式及相应元数据体系的公开查询和调用，因此保障任何系统能够查询到并利用标准方法识别元数据的结构和语义。
1.4 设计元数据的人员要求
为了保证元数据设计的有效性和可用性，在设计元数据时具体项目的负责人应全程参与元数据的设计。系统分析人员要能够清晰描述系统需求，并勾画领域模型，为元数据的设计打下良好基础。元数据设计人员要在领域模型的基础上，选择和定义数据元素，对系统元数据进行详细设计。信息技术人员要熟悉资源描述规则和形式化描述语言等。参与元数据设计的相关人员除了对元数据的相关理论方法较为熟悉外，还应能理解互联网的相关概念和理论，数据管理人员应对各元数据的结构和元素的内容及含义进一步细化和解释。
-
2 元数据应用框架
数据环境的复杂性使得描述数据的元数据不可能或不应该由单一的元数据规则来描述，各类应用的发展产生了多样化的元数据规范，以满足各类数据描述需要。但是在数字环境下，设计的元数据应能满足数字环境下开放性的要求，本指南借鉴DC元数据应用纲要[2]（Framework for Dublin Core Application Profile (DCAP)，）的要求来指导和约束各个系统和项目所开展的元数据的设计工作。本指南根据DCAP的流程化思想建立了一个设计元数据的通用技术框架，见图1。旨在确定建立元数据的基本流程和方法，据此设计的元数据满足各个方面和系统应用元数据的需要，是一个通用的元数据规划模型。
该模型定义了一套流程和方法去制订元数据，基本流程包括：
（1）功能需求分析，即为什么要设计元数据，这套元数据要达到什么目的，应用的具体需求是什么；
（2）领域模型构建，即元素集合和相互关系定义；
（3）设计元数据记录；
（4）编制使用指南；
（5）计算机描述语言进行形式化描述。
图1 元数据应用框架
本指南更多关注元数据设计的流程和方法，将其作为设计元数据的路线图，据此规划设计符合开放性要求的描述数据和资源的元数据，满足NSTL完整数据业务流程中规范设计元数据的需求。
-
3 功能需求分析
3.1 功能需求的必要性
任何元数据设计的目的都是为了支持某项活动，而为该活动中的应用确定明确的目标是非常关键的第一步。功能需求就是确定应用目标和应用活动范围的重要组成部分。如果应用目标立足点较高或实现较为困难，可参考马斯洛需求层次理论对目标进行分解。明确的功能需求将用来约束元数据应用的边界。
3.2 如何创建合适的功能需求
合适的功能需求应该是能满足资源用户和应用开发者的需要，根据这样的需求设计出来的元数据才能够支持系统的应用。功能需求设计至少应回答以下问题：
1）元数据应用要实现什么功能，应用的边界是什么，哪些功能不能实现？
即设计元数据时应明确应用的目的和主要功能，同时还要清楚地了解该应用的功能局限，哪些功能不能实现。
2）应用如何服务用户？
即该应用如何实现与用户之间的交互，如何满足用户的需求，用户通过怎样的操作才能获得自己想要的结果。
3）应用有哪些专门的操作？
明确应用所要求的专门的操作，比如排序、下载特有格式的数据等。只有这样才能够保证元数据充分满足该应用所有的功能需求。
4）元数据所描述资源的核心特点是什么？
不同的资源具有不同的特点，这些特点将会影响元数据元素的选择。需要根据所描述资源的核心特点来定义元素，以确保元素的定义全面合理。
5）系统所服务用户的特点是什么？
即系统是服务专门用户还是大众用户，这些用户的主要语言是什么，他们有多了解所描述的数据对象。只有充分了解目标用户才能保证元数据设计满足用户的需求。
6）有没有相关的描述标准？
即是否存在与自己的应用设计相关的元数据规范，这些规范的设计特点是什么，其中有哪些内容是可以借鉴的。
3.3 功能需求创建过程及方法
创建功能需求时推荐参考DCAP发展方法（A method for the Development of Dublin Core Application Profiles(Me4DCAP)）[3]。Me4DCAP定义了功能需求创建的四个步骤，即工作计划、愿景描述、功能需求表达和用例模型。具体的创建过程如下：
（1）工作计划
工作计划即规定项目的起止时间以及中间各步骤完成的时间点。同时它还规定了各个参与成员的责任。工作计划通常是由工作团队各成员共同协商制定的，并且可以根据项目需要进行不断修改。工作计划可以是文本形式，也可以是甘特图或者其他任何图表形式。
（2）愿景描述
愿景描述展现了应用要达到的目标，定义了功能的范围和界限，它通常以文本的形式存在。愿景描述采用头脑风暴的方法得出，即团队成员集思广益，通过不断的讨论修改得出最终的结果。TBM DCAP[4]、WSDM方法[5]以及 RUP 等的研究都将愿景描述作为功能需求创建的重要一步。
（3）功能需求描述
功能需求表是由工作团队，特别是最终用户以及项目管理者提出的功能需求列表。功能需求的归纳可以采用与愿景描述同样的方法，需要团队全体成员的参与。在用例模型阶段，功能需求表也会进一步细化。
（4）用例模型
用例使得功能需求的创建更加系统和直观，用例能够更好地理解所研究的实体和属性。为保证实现系统功能，每个用例都要对必须完成的工作给出详细的说明。用例模型主要包括两个部分：1）UML用例图。该用例图包括在用例之间起相互作用的角色。它详细描述了系统的功能。2）所有详细用例的集合。该集合包含各个具体的用例以及对于每个用例的详细介绍。
可参考的用例模型包括TBM DCAP[4]、VMAP、Images Application Profile (IAP)[6]和DRYAD[7]等等。
经过以上四个步骤形成的功能需求包含了一般的以及特定的需求。团队中的每个成员都可以提出自己的功能需求想法，然后检验是否存在重复的功能需求，同时要保证每一个成员的特定需求都得到满足。最终的结果需要由全体成员讨论得出。
除了上面提到的创建方法，还有其他一些收集需求的方法，比如Scholarly Works Application Profile(SWAP)[8]需求收集的方法有：
（1）查阅现有的实例。例如：
eprints.org - e-Prints Soton[9]
DSpace - Edinburgh Research Archive[10]
Fedora - Queensland QUT[11]
Other - CCLRC ePubs[12]
（2）查阅现有的或者已经提出的应用纲要。例如：
Eprints UK - Using simple Dublin Core to describe eprints[13]
DSpace - DSpace metadata[14]
Arrow discovery service, Australia - ARROW application profile[15]
Swedish SVEP project Metadata model[16]
（3）工作组或者更广泛的团队之间的讨论
开发过程往往需要多团队之间的合作，可能包括服务管理团队、相关领域的专家、应用的开发者，以及潜在的最终用户等。不同角色的团体成员对于需求会有不同的认识和理解，因此成员之间的交流讨论有助于需求的广泛收集，这也是需求确定的一个重要途径。
（4）收集/编写使用场景和用例
编写特定应用的场景和用例有助于特有需求的创建，以避免某些特有的功能需求被忽视。比如SWAP中的需求“Copy is made available by”，它的使用场景就是：一个用户或者服务想要了解资源的其他副本、其他服务或者知识库是由谁提供的。
3.4 功能需求创建实例
一般的文献数据库包括期刊论文、会议论文、学位论文、文集汇编和科技报告。期刊论文、会议论文及文集汇编都是集结出版的文献，学位论文和科技报告则通常是单篇或者成册出版[17]。那么文献数据库元数据从功能上应支持：
（1）文献选择，包括：①按类型选择文献；②根据文献主题和内容选择文献；③根据文献引用频次选择文献。
（2）文献识别，包括：①根据文献特征识别；②识别文献作者及其所在机构；③通过全球通用的DOI识别文献；④通过本地通用的Local DOI识别文献；⑤识别所描述对象是否有纸本全文。
（3）文献获取，包括：①检索文献主题和文摘；②支持多语种的文献检索；③支持OpenURL链接服务器对检索结果的调用，帮助实现原文获取；④支持在NSTL成员馆范围内的全文获取。
（4）数据管理，包括：①实现按文献品种分配加工任务，避免重复加工；②按本册管理加工进度；③根据加工深度要求（加工题录、文摘或是引文），安排加工任务；④支持OAI协议对数据的收割。
另外的一个例子，功能需求的设计必须支持某些用户任务，比如Functional Requirements for Bibliographic Records [FRBR][18]中的如下任务：
（1）利用数据找到符合用户搜索条件的材料
比如搜索特定主题的所有文献，或者搜索某个标题下的出版记录等。
（2）运用检索来确定一个实体中的数据
例如要确定某条记录中所描述的文献与用户搜索的文献相一致，或者能够有效区分具有相同标题的两个文本或者记录。
（3）利用数据来选择符合用户需求的实体
例如选择的文本应该具有用户能够理解的语言，选择的计算机程序要与用户的硬件以及操作系统相兼容。
（4）利用数据能够获取或者访问所描述的实体
例如对某个出版物下采购订单，请求借阅馆藏中某本书的副本，或者能够访问远程计算机中的电子文献等。
功能需求也应包括需要解决的问题的总体目标和具体任务。这方面可参考的例子是Scholarly Works Application Profile [SWAP]，它的功能需求中的总体任务有：便于识别的开放获取的材料。具体任务有：
（1）全文识别，即提供一种能够链接到全文的有效方法。
（2）版本识别、不同版本之间的导航。
（3）研究资助者和项目代码识别。
（4）OpenURL，即支持从检索结果到OpenURL链接服务器之间的转换。
（5）扩展性，即该应用支持对于其他类型资源的可扩展性。
（6）责任声明，即能够获取资源的作者信息。
（7）研究资助者和项目编号，即可以识别研究资助者和项目编号的功能等。
功能需求分析是元数据制定过程中的重要组成部分，在创建过程中要充分考虑到各个方面的需要。根据确定的创建和收集功能需求过程和方法，并参考现有的功能需求创建实例，制定符合目标应用的功能需求。这个过程需要工作组或者整个团队成员的广泛参与，各成员提出自己的功能需求想法并在团队之间进行交流讨论，最终得出全面详细的功能需求分析报告。
-
4 领域模型构建
4.1 领域模型的界定
功能需求确定后，下一步就需要选择或者设计领域模型。领域模型是抽象描述现实世界的一种工具和方法，是通过抽象的实体及实体之间联系的形式，来表示现实世界中事务的相互关系的一种映射。实体主要指现实世界中存在的可以相互区分的事务或概念。
创建领域模型可以提高模型的抽象层次，减少思维与软件模型之间的表示差距，并促进对问题的理解。领域模型一方面需要具有较强的语义表达能力，能够方便直接地表达应用中的各种语义知识，另一方面还需要尽可能地简单、清晰并易于理解。
领域模型决定哪些资源需要被标识和描述，是数据元素选择和定义的基础，也是进行元数据设计的蓝图。描述领域模型时，重点表达对象以及对象之间的关联，而先忽略对象的属性。对象的属性在详细的数据模型设计中进行描述。
4.2 领域模型建立的步骤
领域模型主要表现的是抽象的实体对象和实体对象之间的关系，通过对实体对象和实体对象之间关系的定义和描述，来表达实际的业务中具体的业务关系。领域模型通常是在功能需求分析的基础上进行建立的，可以复用或参考其它外部定义的数据模型，同时需要考虑具体应用和元数据设计的互操作性。
领域模型建立的步骤主要包括三个步骤：
（1）根据具体的功能需求确定实体对象，并对实体对象命名。
在对需求进行逻辑分析后，对业务进行初步的归纳和提炼，抽取关键业务概念，并将之抽象化，确定需要标识和描述的实体对象，并对它们进行命名和定义。实体对象可以从符号、内涵和外延进行考虑，符号是表示对象的词语，内涵是对对象的定义，外延是一组示例。可以通过重用或修改现有模型中的实体对象，或使用领域术语，或通过语言分析技术从领域文本中识别相关概念作为候选对象等。实体是领域模型的最小单元，是不可再分的。
（2）确定实体对象之间的相互关系，定义实体对象之间的关联和约束。
实体对象不是孤立存在的，他们之间存在各种各样的关系，通过细化和理清业务流程之间的关联，抽象实体间相互的关联性，形成完整的领域模型。实体建模法能够很容易地实现业务模型的划分，因此，在领域建模阶段，实体建模法有着广泛的应用。实体建模法作为用于描述实体间关系的重要方法，也能应用于更详尽地描述实体之间的特有关系。例如，人事信息系统的模型会显示可能存在于一个雇员与另一雇员间的关系（如夫妻关系）。如果这些关系对于这一模式化领域的信息用户是重要的，就应该定义为模型的一部分。
（3）采用一定的