-
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）采用一定的描述方式展示领域模型，以方便业务人员和技术人员之间的交流和沟通。
领域模型既可以采用图形方法说明，也可以采用文本方法描述。领域模型的描述方法和方式主要有UML（Unified Modeling Language，统一建模语言）、ER（Entity-Relationship diagram，实体关系图）、ORM（Object Role Modeling，对象关系模型）、ORT（Object Modeling Technique，对象模型技术）等。其中，UML、ER、ORM是领域模型常用的描述方式。
UML是一种定义良好、易于表达、功能较强的面向对象建模语言，通过UML表示法，领域模型被描述为一组没有定义操作的类图，提供了对象透视图，可以展示领域对象，对象之间的关系，对象的属性等。为了描述方式的统一，本指南要求使用UML描述领域模型。
4.3 领域模型的检验
领域模型建立后，需要从以下几个方面对模型进行验证确认。
（1）该模型是否分析出了足够的实体对象，并描述了它们之间的关系；
（2）如果该模型采用了外部定义的数据模型，该模型是否被明确标识；
（3）被引用的模型与本应用是否有不同之处；
（4）应用中使用的领域模型是否基于广泛使用的模型，例如书目记录功能需求FRBR（Functional Requirements for Bibliographic Records）就是图书馆描述书目资源时所使用的一个重要的参考模型。
4.4 领域模型实例分析
采用UML进行领域模型的描述，主要目的是借助UML 定义一致的事物名称和术语，实现不同用户群体之间准确的沟通。下面采用UML来描述MyBookCase领域模型和SWAP领域模型。
（1）MyBookCase领域模型
MyBookCase有两类实体对象: 图书（book）和作者（person），一个关联关系：图书和作者的撰写关系（is authored by）。MyBookCase的领域模型具体如图2所示。可以用题名（title）和语种（language）等元数据来描述图书，可以用人名（name）和邮箱地址（email）等元数据来描述作者。
图2 MyBookCase的领域模型
领域模型可以比MyBookCase的模型简单些，也可以选择和设计复杂的领域模型。例如，SWAP(Scholarly Works Application Profile，学术作品应用纲要)的领域模型主要是基于FRBR模型构建的。SWAP定义了专门的学术作品对象，而没有采用FRBR的一般实体对象“Work”。与FRBR模型相比，SWAP引入了一些新的对象关系，如“isFundedBy”（被赞助）、“isSupervisedBy”（被监督）等。总之，SWAP是在FRBR基础之上，进行了一些个性化定制，以满足它的特殊需要。
SWAP的领域模型具体如图3所示。SWAP的领域模型由学术作品(Scholarly Works)、内容表达(Expression)、载体表现(Manifestation)、副本(Copy)和代理(Agent)五种实体对象及其之间的关系描述组成。SWAP的学术作品(Scholarly Works)相当于FRBR中的作品（work），copy相当于FRBR中的单件（item），Agent相当于FRBR中的个人或者团体。
图3 SWAP的领域模型
4.5 详细的数据模型
设计和确定领域模型后，如果认为模型描述的不够细致，还可以把领域模型具体化，形成详细的数据模型。根据元数据设计模块化原则，通常每一类资源的描述包含有多个元素集和元素集的相关关系。下面是用UML描述的期刊论文资源的数据模型图。
图4 期刊论文的数据模型
对期刊论文的描述包含有8个元素集，分别是论文元素集、作者元素集、卷期元素集、期刊元素集、馆藏元素集、机构元素集、项目元素集和主题元素集，它们之间的关系可以概括如下
一篇期刊论文由一个或多个作者创作；一篇期刊论文包含于特定期刊的特定卷期中；特定期刊卷期包含于/属于某一种期刊；一种期刊被一家或多家机构出版；特定期刊卷期被一家或多家图书馆收藏；一个作者属于一个或多个机构；一篇期刊论文由一个或多个项目资助；一个项目被一家机构资助；一篇期刊论文由一个或多个主题。
-
5 元素选取和定义方法
5.1 元素选择方法
领域模型定义完成后，需要选择合适的元素来描述模型中的资源对象，如图书(book)可以通过题名(title)和作者(author)元素进行描述，个人(person)可以通过姓名(name)和邮箱(email address)元素进行描述。
元素的选取需要遵循一定的规则：
（1）元素可以取自于一个或多个URI命名域
通过公开的可以访问的资源标识符，保证所引用的元数据元素是规范的可辨识的，同时保证元数据的互操作能力；
（2）复用已有元数据规范中的元素
目前已有丰富的元数据规范对数据元素进行定义，例如，DC、FOAF、BIBO、JATS、Dryad等，选取元素时首先对这些元数据规范进行扫描，筛选出与需求相符的元数据规范并进行分析，然后复用筛选的元数据规范中定义的元素，在已有元数据规范没有定义所需元素的情况下，可根据实际应用需要增加新的元素。对于同一系统或同一体系中的元数据，描述相同对象的数据元素要统一，以保证系统内部和系统间数据元素的一致性。
（3）自定义元数据规范中的元素
一种情况是已有元数据规范没有定义所需元素，可根据实际应用需要自定义新的元素，如前所述。一种情况是不对元素进行复用，直接采取自行定义的方式，对于这种情况，需要对自定义的元素和已有的较为通用的元数据规范进行映射对照，以获得最大的语义兼容性，并提高元数据间的互操作性。
（4）自定义相关的编码体系
在引用已有元数据规范中的元素时，既可以直接采用其对应的编码体系，如引用日期(date)时，取值也遵守W3C标准格式，也可以对所引用的标准元素进行适应本地化实际需求的裁剪，如主题(subject)的词表编码体系可以是美国国会主题词表(LCSH)，也可以是汉语主题词表。
对于编码体系的进一步定义或采用更为切合实际需求的本地化编码体系是实现元数据语义的本地适合性的重要一环，也可以视之为元数据语义本地化应用的必要条件之一[19]。
（5）可根据需求定义元素结构
在简单描述（如描述作者时仅使用姓名或出生年元素）不能满足需求的情况下，可以使用复杂结构（如从姓名、邮箱和所属机构等多方面描述作者）进行描述，并定义各个元数据的元素之间的相互关系，比如元素与子元素之间的关系，上位类与下位类的关系，又比如元数据中元素与修饰词的关系等。
人们一般根据特定应用领域的成熟信息处理框架或标准来决定元数据的内容结构，并在元数据定义中对此进行说明，例如MARC根据ISBD，EAD根据ISAD（G），ICPSR依据ICPSR Data Preparation Manual，SCORM依据ADL/SCORM、NEDLIB依据OAIS。
5.2 元素定义方法
ISO/IEC 11179标准“数据元素的基本属性(Basic Attributes of Data Elements)”[20]。以Dublin Core元素为例，早期从ISO11179标准中选取了10个属性进行定义[21]，其中Name属性是赋予元素的一个给人识别的标签，Identifier是机器可读标签，如此定义会产生大量的冗余信息。目前DC把给人读的标签换为Lable属性，并明确把URI作为Identifier，Name属性就作为一个机读的token，并将属性分为必备属性和有则必备属性[22]。
JATS标准，推荐从以下9个方面对元素进行定义，如表2所示。很多元数据方案如Web of Science元数据、Scopus元数据、JATS元数据等都引用了属性描述元数据，属性能将表达相同或相似内容的元素进行归并，在参考JATS标准的基础上，本指南推荐从以下6个方面对属性进行定义，如表3所示。表2 元素定义表
表3 属性定义表
Instructions）。为了准确使用元数据，应该在定义元素时明确定义相应的编码体系。编码体系分为词表编码体系和语法编码体系[21]。词表编码体系是指元素的属性值取自某受控词表，如描述主题的词表编码体系可以是LCSH、MESH、DDC或UDC等。语法编码体系是指字符串的值的格式遵循某一标准或规范，如日期的内容编码体系遵循ISO8601标准。推荐使用的编码体系标准见附录1。
OhioLink在使用VRA Core时要求主题元素使用AAT（Art Architecture Thesaurus）、TGM（Thesaurus for Graphic Materials）和TGN（Thesaurus of Geographic Names），人名元素用ULA(Union List of Artists Names)。5.3 元素选取实例分析
以MyBookCase为例，选取描述图书(book)的元素需要考虑以下几个方面：
（1）元素是否来源于图书本身，例如题名(title)必须来源于图书本身，取值为自由文本；（2）元素是否以多种形式进行应用，例如日期(date)显示格式必须统一，以便对检索到的书目记录进行排序；（3）如何保证元素取值的一致性，例如采用控制词表保证图书语言(language)元素取值的一致性；（4）如何对取值进行规范，例如采用受控词表如LCSH提取主题词，保证取值规范性；（5）元素是简单元素还是复合元素，例如作者(author)不是单一的文本字符串，通过姓名、邮箱等子元素描述。
上述分析将产生以下数据模型：
（1）题名(title)：可以使用元素article-title或RDA元素rda:title，取值为自由文本；（2）日期(date)：可选择元素date，取值为字符串。通过语法编码体系dcterms:W3CDTF表明取值遵循W3C日期和时间格式标准；（3）语言(language)：采用ISO 639-1国际标准，使用元素dcterms:language或RDA元素rda:languageOfExpression，取值既可以是唯一标识符也可以是字符串；（4）主题(subject)：可选择LCSH作为词表编码体系，使用元素dcterms:subject。（5）作者(author)：作者需要从多个方面描述，如姓名和邮箱。可以使用dcterms:creator，取值为非文本值。姓名要将姓和名分开标记，DCMI中没有相关元素，可以使用FOAF元素foaf:firstName和foaf:family_name，邮箱可以使用FOAF元素foaf:mbox，为非文本值。
-
6 设计元数据记录
元数据记录描述了元素以及元素之间的关系。在确定元素后，下一步要详细设计与描述元数据记录结构。设计元数据记录结构需要考虑的问题包括元素的出现频次、元素取值、编码体系、元素出现的顺序、元素间的交叉引用关系等相关的技术细节约束。只有考虑清楚这些技术细节约束，才能形成良好的元数据记录。如果元数据记录的元素和相关结构已考虑的非常清楚，可通过形式化语言描述出来便于计算机理解。
以MyBookCase的元数据记录设计为例进行说明。MyBookCase的元数据记录有两个实体对象：书和人，书的描述元素包括题名、创建日期、主题、作者，并按顺序出现；作者的描述元素包括姓、名和邮箱，也按顺序出现。将书出现次数设为一次，假设每本书有且仅有一个题名，描述元素为title，取值类型为字符串；可能有多个主题词，即最小出现次数为0次，最大出现次数为无穷尽，描述元素为subject，取值为字符串；可能有多个作者，将最大出现次数设为5个，取值类型为复合型，作者姓使用family_name描述，可能有一个，名使用given_nam描述，可能有多个，取值都为字符串，邮箱使用email描述，也可能有多个，取值为URI。
此实例中一些元素的最小出现次数为0，这是表明此元素为可选，即没有元素，元数据记录也是有效的。一些元素是可重复的，如一篇论文有多个作者。一个作者可以有一个可选的名、一个可选的姓，也可以有邮箱，邮箱必须是URI。由于一个人可能有多个邮箱，故邮箱允许出现多次。每个作者的描述数据代表了一个作者，如果有两个作者，则元数据记录中需要有两个作者描述，允许一个作者有多个姓名的存在，如真实姓名和笔名。如果需要描述作者所在机构信息，则创建包含机构名称、机构地址的描述信息，并与作者描述相联系。
-
7 使用指南
使用指南提供元数据的著录规则，解释原因并指导人们创建元数据。理想状态下，使用指南解释每个元素，预测在元数据创建过程中产生的问题并做出指导。提供给元数据创建者的文档中包含了与元数据记录结构中相同的一些信息，相较于元数据记录更便于人理解。这些输入的元数据需要明确：属性是否必要？是否具备可重复性？该属性可否使用限制值？通常在用户界面可以解决的问题，例如为元数据创建者提供有效值列表。
使用指南中的某些规则可能如下：
（1）对于多个作者合著的成果，如何对作者进行排序，著录多少个作者，如“前三”、“不超过20”）；
（2）如何解释文档类型的专有词汇？
（3）“最小”记录所必备的元素有哪些？
（4）字符串包含字符、标点符号和缩写。
有些情况下使用指南比较简单，对元素的描述直接包含于元数据记录文件中。如学术作品应用纲要的使用说明就包含于元数据记录结构中。
有些组织规则繁杂，因其内容长度长和复杂程度高，使用指南需要单独的文档。如作为图书馆编目指南的英美编目规则是一本长达600页的书。其内容涉及多个章节标题，涵盖多页文档，使用指南最好与元数据记录分离。使用指南可以由管理人员和元数据程序员来管理，而元数据对象的属性和类的描述信息，必须由学科专家填写。
-
8 元数据形式化描述
本文档中描述的技术是语法中性。也就是说不要求任何特定的机器可读编码的语法，只需要语法能充分表达元数据中的值和关系。为了帮助开发人员将应用文件开发为应用软件，DCMI开发了各种编码指南[23]。目前已经或正在采用HTML/XHTML、XML以及RDF/XML开发元数据的编码指南，未来可能添加其他形式。只要产生的数据格式符合兼容的基础标准和语义标准，不限制语法类型。
语法指南因其是技术文档，必须由应用的程序员编写。元数据语法是将元数据形式化描述，即将元数据规范体系的所有语义、结构及描述的内容以人可读或计算机可读的形式化方式描述出来，并满足标准、开放、互操作，以及人机可读的要求，其中以XML语言应用为多。本指南推荐使用XML语言实现元数据形式化描述，以XML文档实现数据的传递和交互，以XML Schema实现数据验证。关于XML语言的描述见附录2。
-
参考文献
[1] 张晓林.元数据研究与应用[M].北京：北京图书馆出版社.2002.
[2] Guidelines for Dublin Core ApplicationProfiles[EB/OL].[2015-03-26].
http://dublincore.org/documents/profile-guidelines/.
[3] Mariana Curado Malta ,Ana Alice Baptista.Me4DCAP-Detail [R].Portugal: University of Minho,Algoritmi Center,2013.
[4] CalverleyGayle,JohnstonPete.Time-based Media Application Profile: Definition Phase Report[EB/OL].[2015-03-04].http://wiki.manchester.ac.uk/tbmap/images/5/5c/TBMAP_Definitionreport_v3_final.pdf.
[5] De Troyer, O. M. F., LeuneCorneli J. WSDM: a user centered design method for Web sites[J]. ComputerNetworks and ISDN Systems, 1998,30(1), 85–94.
[6] Eadie Mick. Towards an application profile for images[J]. Ariadne, 2008,55.
[7] CarrierSarah. The Dryad repository application profile: Process, development, and refinement[EB/OL].[2015-03-06].http://dc.lib.unc.edu/cdm/ref/collection/s_papers/id/1042,2008.
[8] Scholarly Works Application Profile[EB/OL].[2015-03-06].
http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_Application_Profile.
[9] ePrints Soton[EB/OL].[2015-03-06].http://eprints.soton.ac.uk/.
[10] Edinburgh Research Archive[EB/OL].[2015-03-16].https://www.era.lib.ed.ac.uk/.
[11] Queensland QUT[EB/OL].[2015-03-16]. http://eprints.qut.edu.au/.
[12]ePubs[EB/OL].[2015-03-16]. https://epubs.stfc.ac.uk/index.
[13] PowellAndy, DayMichael, CliffPeter. Using simple Dublin Core to describe eprints[EB/OL].[2015-03-16]. http://eprints-uk.rdn.ac.uk/project/docs/simpledc-guidelines/ .
[14] Dspace metadata[EB/OL].[2015-04-06]. http://www.dspace.org/technology/metadata.html.
[15] ARROW application profile[EB/OL].[2015-04-06]. http://www.arrow.edu.au/docs/files/harvesting.pdf.
[16] SVEP project Metadata model[EB/OL].[2015-04-06]. http://www.svep-projekt.se/masters-theses/Metadata_model/
[17] 张建勇.文献数据库数据加工规范[M].北京:知识产权出版社, 北京,2009.
[18] Functional Requirements for Bibliographic Records[EB/OL].[2015-04-06]. http://www.ifla.org/VII/s13/frbr/index.htm.
[19] 赵亮,楼向英,张春景,刘炜.元数据应用:语义、结构与句法[J].图书馆杂志,2004,07:49-55.
[20] ISO11179[EB/OL].[2015-03-14].http://metadata-standards.org/11179/.
[21] Dublin Core Metadata Element Set, Version 1.1: Reference Description [EB/OL].[2015-03-04].http://dublincore.org/documents/1999/07/02/dces/.
[22] DCMI Metadata Terms[EB/OL].[2015-03-24].http://dublincore.org/documents/dcmi-terms/.
[23] Encoding Guidelines[EB/OL].[2015-03-24].http://dublincore.org/resources/expressions/
-
附录1 推荐的编码体系标准
1. 国家编码标准
名称：GB/T 2659-2000，世界各国和地区名称代码
2. 语种编码标准
名称：GB/T 4880.1-2005，语种名称代码 第1部分：2字母代码ISO 639-1
参见：http://www.mathguide.de/info/tools/languagecode.html
3.日期编码标准
名称：GB/T 7408-2005 数据元和交换格式 信息交换 日期和时间表示法（ISO 8601）
4. 词表编码标准
名称：中国图书馆图书分类法CLC
参见：http://www.ztflh.com/
名称：中国科学院图书馆图书分类法LASC
名称：杜威十进制图书分类法DDC
参见：http://www.oclc.org/dewey/
名称：美国公立图书馆分类法LCC
参见：http://lcweb.loc.gov/catdir/cpso/lcco/lcco.html
名称：美国国会图书馆标题表LCSH
参见：http://purl.org/dc/dcam/VocabularyEncodingScheme
名称：国际十进分类法UDC
参见：http://www.udcc.org/
名称：美国医学主题词表MESH
参见：http://www.nlm.nih.gov/mesh/meshhome.html
名称：汉语主题词表
参见：http://adv.agri.org.cn/hanyucibiao/cibiao.asp
-
附录2 形式化描述
XML（Extensible Markup Language）语言包含了一组定义语义标记的规则，可以定义特定领域内标记语言的语法结构。
1. 形式化描述
元数据形式化描述包括两个方面的内容，一方面是有关元数据规范的定义与描述；另一方面是有关元数据记录的描述。从系统应用的角度，前者如数据词典或数据库结构。而后者则为数据记录。
DTD和XML Schema是常用的标记扩展语法，RDF是专用元数据描述语法，以上语法利用XML的标记可扩展性来标记和定义合法的XML文档构建模块。
（1）DTD
一个XML文档只能对应一个DTD，其由元素定义，属性定义，实体定义，注释定义组成，例如，一个简单的含有DTD的XML文档定义如下：
通过上述例子发现DTD可以简单的描述元数据，但DTD提出较早，在使用过程中发现其很多不足，主要是较难理解和书写，其采用的EBNF语法需另外了解；不支持命名域（Namespaces）如需对已有DTD进行扩展，那么只能重写源文件。
（2）RDF
介于DTD的缺点日趋严重，W3C（Word Wide Web Consortium）提出了替代DTD的方案，如RDF和XML Schema。RDF主要解决XML描述元数据资源对象时的二义性问题。RDF不仅可以定义对象，还可以加入属性来描述和定义对象以及声明资源间关系等。RDF基本对象包括：资源、属性和声明。例如，一个简单的RDF定义如下：
通过上述例子发现RDF具有以下特点：由于RDF使用三元组（资源-属性-值），使得描述易于控制；在元数据模型中可嵌入其他类型元数据。但是RDF在日常应用中使用较为复杂，元数据设计者不仅需要定义对象和属性，而且还需要定义复杂的声明。
（3）XML Schema
XML Schema是基于XML的DTD替代者，可描述XML文档的结构，也可作为XSD（XML Schema Definition）来引用。一个Schema可定义内容包括：文档中的元素，文档中的属性，哪个元素是子元素，子元素的次序，子元素的数目，元素是否为空，或者是否可包含文本，元素和属性的数据类型以及元素和属性的默认值以及固定值。一个简单的XML Schema定义的XSD文件如下：
通过上述例子发现XML Schema自身为XML文件，但Schema文件描述的是引用它的XML文件中的元素和属性的具体类型。XML Schema拥有以下特点：借助XML语言的特性和语法规则来定义XML文档结构；引入数据类型，通过对数据类型的支持，可更容易地描述允许的文档内容，验证数据的正确性，定义数据约束（data facets）和数据模型（或称数据格式）在不同的数据类型间转换数据；引入命名域，通过命名域的方式注明元数据来源，元数据格式在经过这样的描述和封装后，可以方便地被计算机系统读取；可利用Schema文件验证XML文件合法性，同时约束XML使用的规范性。
2. XML Schema书写语法
从模式的描述语言来说，XML Schema属于语法模式，与概念模式不同，语法模式在对同一事物描述时，可以采用不同的语法，例如在对关系模式描述时，既可以用元素也可以用属性来描述关系模式的列。XML Schema事实上也是XML的一种应用，所以它理所当然的继承了XML的自描述性和可扩展性，这也使得XML Schema 更具有可读性和灵活性。本文中将对XSD实例文件进行分析来说明XML Schema书写语法。
2.1数据类型
XML Schema提供了数据类型，并且支持自定义数据类型，但这一切都是建立在内置数据类型和一套扩展内置数据类型的规则基础之上的。数据类型图如图1所示：
图1 数据类型图
从上面的XSD数据类型图可以看出，主要分成两个大类：
简单类型：可以给属性使用，也可以给元素使用，除了内建类型，也可以使用自定义简单类型，而自定义的方式有三种：限制、列表、联合。
（1）内建类型
首先引入一张W3C标准XML Schema官方文档中的内建类型关系图如图2所示：
图2 内建类型关系图
1）字符串
字符串数据类型可包含字符、换行、回车以及制表符。声明例子如下：
规格化字符串数据类型源自于字符串数据类型，可包含字符，但是XML处理器会移除回车以及制表符。
Token数据类型同样源自于字符串数据类型，可包含字符，但是XML处理器会移除换行符、回车、制表符、开头和结尾的空格以及（连续的）空格。
字符串类型衍生表如下表所示：
2）数值
十进制数据类型用于规定一个数值, 规定的十进制数字的最大位数是 18 位。声明例子如下：
整数数据类型用于规定无小数成分的数值。声明例子如下：
float和double类型可以接受的特殊值：-INF（负无穷大）、INF（正无穷大），NaN（非数）、+0（正零）和-0（负零）。其中正零大于负零，NaN大于所有数值（包括INF），INF大于所有浮点数。
数值类型衍生表如下表所示：
3）布尔
布尔类型可以接受true、false、1（表示true）、0（表示false）四个值。声明例子如下所示：
4）日期和时间
日期数据类型用于定义日期。日期使用如下格式进行定义："YYYY-MM-DD"，其中YYYY表示年份，MM表示月份，DD表示天，且此三项为必备。声明例子如下所示：
时间数据类型用于定义时间。时间使用如下格式来定义："hh:mm:ss"，其中hh表示小时，mm表示分钟，ss表示秒，且此三项为必备。声明例子如下所示：
日期时间数据类型用于定义日期和时间。日期时间使用如下格式进行定义："YYYY-MM-DDThh:mm:ss"，其中YYYY表示年份，MM表示月份，DD表示天，T表示时间部分开始，hh表示小时，mm表示分钟，ss表示秒，且以上均为必备。声明例子如下所示：
日期和时间数据类型衍生表如下表所示：
5）二进制数据
定义两种二进制数据类型，声明例子如下所示：
a) hexBinary：以十六进制保存的二进制数据，因此只能由0~9、a~f、A~F等字符组成，字符长度必须是偶数。
b) base64Binary：以Base64编码保存的任意二进制数据，因此只能由0~9、a~f、A~F和加号+等字符组成，字符长度必须是4的倍数。
6）anyURI
anyURI数据类型用于规定URI。声明例子如下所示：
(2) 自定义简单类型
XML Schema自定义新的简单类型，只能从简单类型派生。对于简单类型只有限制派生没有扩展派生，通过简单派生得到的新的简单类型是其原来类型的子集。XML Schema推荐了标准的12个面（facet）来限制约束。要定义简单类型，使用simpleType元素，要对简单类型进行限制，使用restriction元素。
约束类型的12个面表如下表所示：
限制值的长度，比如需要限制题名的长度为1000。length：内容长度、minLength：最小长度、maxLength：最大长度。主要使用的类型为字符型、QName型、anyURI型。不可以适用于日期、时间、数字和boolean。声明例子如下所示：
需要限定某个数的数字位数，比如支票上最大的单位是亿，最小的单位是分。totalDigits：总数字、fractionDigits：分数数字。声明例子如下所示：
将某个值限定在一组可选的值之中，比如性别要国家选择。enumeration：枚举。enumeration面可以在除boolean以后的其他类型中使用。声明例子如下所示：
有时需要复杂的格式约束，比如需要对邮件地址的格式进行检查。可以使用pattern面进行正则表达式的限制。声明例子如下所示：
复杂类型：只能给元素使用，并且全部需要使用来自定义，根据内容又可进一步区分为含简单内容的复杂类型和含复杂内容的复杂类型，分别使用和定义其内容。另外，复杂类型还可以使用限制和扩展来派生新的类型
一个元素如有属性或者包含子元素，那么这个元素就是复杂类型。复杂类型使用complexType定义。复杂类型要么具有简单内容，要么具有复杂内容。内容是指在开始标签和结束标签之间的字符数据和子元素。简单内容是指内容只具有字符数据没有子元素，简单内容是用simpleContent元素来定义。除此以外的就是复杂内容，使用complexContent来定义。
attribute元素拥有use、default、fixed属性。use属性规定元素是否需要出现，其有效值为：optional（可选，默认值）、prohibited（禁止使用）、required（必须的）。对全局声明的属性不能使用use属性。声明例子如下所示：
default属性指示默认值。属性默认值是有在属性本身为optional时才有意义。如果没有指定该属性的值，那么该值为默认值。如果指定了，则是指定值。声明例子如下所示：
Fixed属性指示固定值。不管该属性出现不出现，该属性的值都是指定值。声明例子如下所示：
如果一个元素的内容是纯元素内容，那么可以用组来构建纯元素的内容。组有3种，分别是：sequence、choice、all。
sequence表示序列，所以组中的所有子元素要按指定顺序出现。如果一个具有复杂内容的复杂类型定义是anyType类型限制派生，那么可以省略complexContent和restriction元素，而直接在complexType元素下使用组。声明例子如下所示：
choice表示选择，即从所有子元素中选择任意一个，且只能使用一个。声明例子如下所示：
all表示任意次序，其中的子元素可以以任意顺序出现，但只能出现一次。声明例子如下所示：
指示符用来控制元素出现的次数，指示符包括minOccurs和maxOccurs，这两个属性可以在组上使用。minOccurs属性指定元素出现的最小次数，maxOccurs属性指定元素出现的最大次数，这两个属性的默认值都是1。unbounded表示不限次数。声明例子如下所示：
2.2 命名空间
(1)常用命名空间
XML Schema引用了三个最常用的命名空间如下所示：
第一个属性是XML命名空间，第二和第三个属性用XML命名空间来标识W3C中的两个XML schema规范。第二个xmlns属性定义了标准的XML schema属性类型例如string, float, integer等。第三个 xmlns属性包含基本的XML schema元素，如element, attribute, complexType, group,simpleType等。
（2）默认命名空间
每一个Schema可以有且只有一个默认命名空间如下所示：
在文档中所有的元素名称前面如果没有前缀的，就是由默认命名空间进行定义和解析的。使用默认命名空间，可以不加命名空间前缀。
（3）源命名空间
在Schema中的定义和声明也可以引用其他的命名空间，可以把这种命名空间取名为源命名空间（source namespaces）。每一个Schema可以有多个源命名空间。
（4）目标命名空间
每一个Schema可以有且只有一个目标命名空间。Xml Schema定义文档中（XSD）定义的一系列元素名称，类型名称，属性名称和属性组名称等的有效作用范围就是在他们的目标名字空间（target namespace）中。实际上，在一个给定的Schema中，每一个名称都是属于一个特定的名字空间的。一个XMLSchema声明如下所示：
（5）命名空间在XML文档中的引用
在XML文档中，命名空间的使用涉及范畴的概念，范畴即命名空间的覆盖范围，它指的是哪些元素和属性在该命名空间中，哪些不在该命名空间中。命名空间既可以限定整个XML文档，也可以只针对XML文档中的一部分。一个XML Schema声明如下所示：
通过例子可以看出，对于标准命名空间和目标命名空间，不需要指定它的SchemaLocation。因为对于目标命名空间来讲，SchemaLocation就是文档自己。对于标准命名空间来讲，它是众所周知的，也不需要指定。而对于源目标空间来讲，就需要指定它的SchemaLocation。elementFormDefault有效值是qualified和unqualified，如果该值是 qualified，XML文档根元素及其下所有子元素都必须通过命名空间前缀限定目标命名空间。这个命名空间必须是schema中定义的targetNamespace；如果该值是unqualified，XML文档根元素必须有命名空间的的限定，这个命名空间必须是schema中定义的targetNamespace。但是其下子元素无须也不允许用命名空间前缀限定目标命名空间。子元素的命名空间为空命名空间。
XML文档和XSD文件没有直接关联，他们之间通过命名空间关联。一个XML文档引用XML Schema声明如下：