元数据范文
时间：2023-03-18 13:12:07
导语：如何才能写好一篇元数据，这就需要搜集整理更多的资料和文献，欢迎阅读由公务员之家整理的十篇范文，供你借鉴。
篇1
关键词：DC 元数据 EAD 电子档案 映射
中国分类号：G250.76 文献标识码：A 文章编号：1674-098X（2013）01（a）-0-03
随着计算机和互联网的普及，来自档案馆、图书馆、博物馆及其他机构的各种数字档案资源如档案、手稿、照片、古籍、个人论文日益增多，大量的电子档案给传统的文件管理方式和理念带来了不小的冲击，如何利用信息技术实现电子档案的科学管理也成为档案界的研究热点。随着元数据技术的发展和应用，利用元数据实现对电子档案的有序管理已逐渐为档案界所接受[1]。
来自于不同软件系统的电子档案常常具有不同的著录格式，它们互不兼容，从而导致不同数据库之间根本无法互相访问和检索，对普通的档案馆来说难以实现无障碍的利用与共享。目前，大多数的研究项目对于分布、异构的数字档案资源只是提供基于互联网的网络链接与检索共享，尚未实现元数据级的互操作，因此无法提供专业化的深度增值服务[2]。解决这一问题的途径之一就是实现元数据的互操作和格式转换。该文将探讨EAD与DC这两种目前应用最为普遍的元数据之间的映射，具备较大的实用意义。
1 DC元数据与EAD
1.1 DC元数据及特点
DC（Dublin Core）即都柏林核心元数据，是目前网络信息资源组织最为通用的元数据格式。DC最早由美国OCLC发起研究，是“用该元素集描述任何网络信息资源，并足够简单以至任何作者无需专门培训即可创建自己文件”的元数据。它由15个基本元素组成，分为三个广为认可的大类，内容描述类包括题名、主题或关键词、资源描述、来源、语种、相关资源和时空范围。知识产权类包括责任者、出版者、其他责任者及权限。外形描述类是指对资源外形特征信息的描述，包括日期、资源类型、资源形式和资源标识。
DC的特点包括以下几方面。
简易性：只有15个元素，而且通俗
易懂；
通用性：不针对某个特定的学科或领域，支持对任何内容的资源进行描述。增加了跨学科的语义互操作性的可能；
可重复性：其所有元素都是可重复的，解决了多著者与多出版者等重复元素的著录问题；
可扩展性：它允许资料以地区性规范出现，并保持元数据的一些特性，以便日后有扩充的余地；
可修饰性：对于需要详细著录的资料，引进了DC修饰词。它遵循向上兼容原则，在范围上对未修饰词的语义进行限定，在深度上对未修饰词的语义进行延伸。
1.2 EAD及其特点
EAD的全称是Electronic Archival Description，即电子档案著录，主要用于著录档案和手稿资源，包括文该文档、电子文档、可视材料和声音记录。它开发于1993年加州伯克利大学的一个研究项目。它是以通用标准语言（SGML）和扩展标记语言（XML）文件类型定义（DTD）的形式存在的[3]。EAD元素集定义有3个层次：EAD头标，著录档案的产生、修订、出版、发行等信息；前事项，著录档案题名页内容；档案著录，是对档案内容及其相关信息的具体描述，包括文件内容、上下关系及增补信息等。
经过多年的研究和发展，EAD受到了档案界和图书馆界的普遍拥护，是美国档案协会的成员们以及一些欧洲国家的档案馆主要使用的元数据，也已成为在世界范围内获得广泛应用的电子档案著录标准。这是由于EAD具有以下特点。
使用了标准通用置标语言（SGML），SGML是电子文献处理与交换的国际标准，用EAD著录的电子档案可以提供网上的信息共享和检索。
不依赖于任何的硬件和软件平台，不需经过任何的转化，在Unix操作系统、Microsoft Windows和Macintosh等环境下都可以很好地被识别。
具有伸缩性，同一部文献既可选用一些简单的标识符著录，也可以选用复杂的等级化的标识符著录。
使用EAD既可以形成新检索工具，也可将已有的检索工具转化为EAD的编码的机读格式。转化时可能要稍作改动或重排，但不需要大量的编辑。
检索功能强。EAD以查询语言（QL）为基础，除了具有一般的检索功能，如布尔检索、截词检索、近似检索以外，还可以在目录中查找单个款目和离散的数
据项。
应用范围广，EAD既可用于手稿，也可用于技术革新、艺术与雕塑、医学、工业等领域的科学资料。
1.3 DC与EAD的比较分析
不难看出，DC和EAD的结构都简单灵活，具有很强的可兼容性、可扩展性和可互操作性，这些特性都使得这两种元数据得到越来越多国家的重视并被广泛应用。对在著录和信息揭示深度上看，DC对资源主题的揭示过于简单，对著录对象的描述深度不够，不能进行专指度较高的检索；EAD则著录详尽，适用范围广泛，检索途径多样[4]。
综观DC与EAD的结构特点和应用性能不难发现，DC的最大特征就是简化的语法系统和有限的元素数量，因此它更具有简易性和亲和力，适用于广泛的资源描述和利用群体；EAD则更为专业化，适合档案专业背景，提供了详尽的资源描述和更多的检索入口，更适用于资源的深度描述和特定学科领域内的深入交流[5]。
2 DC元数据与EAD的映射
2.1 DC与EAD映射表
该文给出DC与EAD的映射表如表1。
2.2 建立映射规则
建立了以上映射表并不能直接完成DC与EAD的映射与转换，仍需针对两种元数据的多种差异建立映射规则，从而使转换完成得更为完整准确。
2.2.1 解决结构上的差异
在映射表中多个元素均为一一对应，但由于两种元数据的结构差异，就产生了源元数据和目标元数据元素间的一对多、多对一或无对应关系的情况出现，如DC的责任者和其他责任者两元素与EAD来源元素的对应为多对一关系，DC的来源、相关资源和版权管理等元素在EAD中则找不到与其相对应的元素。针对这些情况，映射规则必须规定在什么情况下将进行相应转换、如何转换，对无对应关系的元素如何进行转换处理，等等。
2.2.2 解决应用上的差异
由于DC和EAD的结构均灵活多变，存在多种必备和可选元素、可重复与不可重复元素、有无子元素等多种情况。此时映射规则须针对具体情况，做出恰当的规定，如明确规定源元数据必备元素的范围、确定源元数据多个重复元素的可选择性、对一方元数据中子元素缺少对应元素时如何处理，等等。
2.2.3 解决语义上的差异
针对二者语义、数据类型和形式、取值范围不一致等情况做出明确规定，尽量消除差异，确保转换的规范统一。
3 存在问题及解决办法
通过理论研究和多个国家的转换实验，我们发现对DC和EAD进行转换的主要困难还是在于EAD的复杂结构与DC元数据过于简单的矛盾，表现为将EAD转化为DC之后，难以在同一个全宗的档案资料之间重新建立链接，或者难以对由不同数据库收藏的、由同一个人或机构产生的资料之间重建链接；有时会丢失原EAD记录中的上下文信息，或者转换后的著录不够清晰，甚至出现错误指示等[6]。
以上问题的解决措施有以下几方面。
3.1 制订基于DC的电子档案元数据规范
元数据规范（也称元数据标准）是描述某类资源的具体对象时所有规则的集合。一般包括完整描述一个具体对象时所需要的数据项集合、各数据项的语义定义、著录规则和计算机应用时的语法规定。
通过制订针对电子档案的元数据规范，我们可以解决DC诸如对著录对象的描述深度不够、不能进行专指度较高的检索、与原EAD文件结构的对应不够准确等方面的不足。制订能够描述或标识电子档案内容、属性、外观特征及层次结构的描述元数据规范和管理元数据规范，从元素、语法、句法等方面对检索属性集做出规定，在保证数据质量和检索效果的基础上做好检索点设置，提高转换后文件对原文件相互联系的反映准确程度，有效表示转换后文件的可选项等等，确保转换后的元数据质量。
3.2 善用DC修饰词
由于简单DC的15个元素只限于描述信息的单一层次，而EAD是具有等级结构，特别是在EAD内容描述部分的从属部分（dsc）中，可从c01到c12多次重复，并且这些从属部分之间存在密切关联，要靠简单的DC元素来充分表达档案描述之间复杂的层级关系确有一定难度，但是，通过引入适当DC修饰词的复杂DC将能弥补这一缺憾。
目前DCMI（Dublin Core Metadata Initiative，都柏林核心元数据计划）确立了两类修饰词，即元素修饰词和编码体系修饰词[7]。随着各类团体遵从dumb-down（向上兼容）原则提出更多的修饰词，在经过DCMI应用委员会审核批准后推荐给大家使用，由此逐渐形成一个修饰词的大家族。相信不久的将来，通过档案工作者的不懈努力，针对档案专业领域的修饰词也会应运而生，通过多个修饰词的分级复用会较好地解决以上
问题。
3.3 确定DC为我国数字档案馆界的元数据标准
目前EAD在我国的应用仅限台湾，大陆还只处于理论研究阶段[8]；而中文DC的研究与开发则已经从早年的实验阶段步入实用阶段，已设计并制订了期刊论文、电子图书、古籍、家谱和地方志等多种元数据规范，而且使用范围日趋广泛，逐渐为越来越多的图书馆所采用。
数字图书馆的成功范例为数字档案馆做出了榜样。希望我国档案界尽早确立DC为行业元数据标准，加强数字档案馆建设中元数据利用的一致性，少走弯路，尽早实现中文档案信息资源的共建和共享，提高我国档案界的自动化和标准化水平。
参考文献
[1] 张正强.论中国电子档案著录标准化的发展方向[J].图书情报知识，2004（5）：35-38.
[2] 何小菁.数字档案馆元数据编制研究[J].图书情报工作，2004（5）：93-95.
[3] 宋雪雁.档案元数据（EAD）著录原则探析[J].档案学通讯，2009（6）：
57-59.
[4] 王萍，宋雪雁.EAD、DC、TEI著录实例及其比较分析[J].图书情报工作，2006（12）：79-82.
[5] 王小丽，王芳.国内外数字档案馆元数据标准体系比较研究[J].情报科学，2007（3）：382-389.
[6] 王芳，王小丽.基于OAI协议的数字档案馆元数据互操作问题研究[J].现代图书情报技术，2007（3）：18-24.
篇2
关键词：信息资源；特色数据库；元数据；基本原则
引言
随着时代的发展和进步，当前已经进入知识经济时代。网络信息技术的飞速进步，大大加快了信息资源的传播速度；加上层出不穷的社会科研成果，有用的知识信息量急剧增长，使得人们如何通过Internet快速准确的获取所需信息已逐渐成为大家关注的问题。作为重要的知识信息集散地，图书馆长期以来扮演着信息服务的前沿阵地的角色。但是事实是，图书馆根本不可能将所有的出版物收集起来供用户查阅，而且不同用户对信息资源的需求也不限于单一资源，而是希望对国内外各学科科学新动向、新成果、新发展有较为全面的了解，希望能了解一些市场竞争、市场供求的实时动态信息等。因此，图书馆就必须立足自身实际、充分发挥资源优势，完成数字化图书馆的建设，实现资源的整合。而信息资源的有效整合的基础就是元数据的建立。
1 元数据的基本概念
元数据（metadata）又称为数据的数据（data about data）或对其他信息进行描述的信息 （information that describes other information），其作用类似于图书馆中数目卡片。随着现代网络技术的发展，信息资源的快速膨胀给我们带来了诸多难题，而元数据则是解决这类难题的关键所在。元数据能帮助解决的问题主要有以下三个方面：1）有效组织和存储不胜枚数的信息资源，以解决目前URL方式无法满足需求的问题；2）作为一种信息检索方式，帮助人们在浩瀚的信息海洋中快速准确的完成有效信息的检索。目前主流的信息检索方法是搜索引擎，但其带来了庞大的无效信息量，给人们的信息检索造成困扰；3）有效管理巨量的信息资源。为适应如今信息量剧增、瞬息万变的世界，应该及时补充和更新已知的信息，所以要加强专家系统、智能与数据挖掘等新支持系统的研发。因此，元数据主要的功用就是对现有信息资源的有效描述、检索、并对原有信息进行维护、更新和补充，实现信息资源的有效管理和共享。
然而到现为止，元数据仍不存在统一的格式和标准属性，反而具有非常灵活的形式。不同领域的元数据标准也往往不同，如地理空间领域所用的是DGM，音乐资料领域所用的是sMDL，而档案领域应用的却是EAD等等。此外，不同的组织所制定的元数据标准的偏重点也往往有所差异，如MFC、CDF、RDF及Dublin Core（都柏林核心元数据）等，其中影响力最大的当属Dublin Core，其已经逐渐发展成一种通用的元数据标准。且近些年来，我国相关部门已经根据Dublin Core制定出了相应的中文元数据标准，如会议论文、期刊论文（期刊单篇）、电子图书、拓片及音频等元数据的标准。常见的国内元数据标准有CALIS元数据标准和国际科技部元数据标准两种。
2 特色数据库的元数据特点
在高度信息化的现代社会，元数据的使用范围越来越广，特别是特色数据库更加具有针对性，我们必须对其特点做深入的了解，才能更好地对它加以利用。经过仔细研究，能够归纳出以下特点：
1）由于元数据的本质功能是对对象数据进行描述，特色元数据同理，它的本质特点就是描述性，主要利用一些约定俗成的为大众接受的规则对数据进行描述；
2）特色数据库的元数据具有复杂性，因为特色数据库不同于维普、CNKI等这样的商业数据库，它包含的资源多种多样，包括期刊单篇、图书、会议论文甚至是音频、视频等内容，另外，特色数据库里面的数据除了以一次文献，可能还有综述、摘要、关键词等内容，要对特色数据库建立元数据，就必须考虑特色数据库的各方面的内容，元数据的检索也要涵盖各方面的内容，相对来说较为复杂；
3）特色数据库中对某些字段的定义难免不够标准。因为特色数据库中的资源类型繁多 ，部分不在相同资源类型中的相似内容很有可能在相同的字段中定义，比如时间，图书的出版时间可能会和会议举办的时间共同归纳在数据库的“时间”的字段当中，再如，不同文献类型中的页码都可能归纳在数据库的“页码”字段；
4）部分满足现有标准的必备元素在特色数据库中没有被准确定位，在特色数据库建立初期，相比于数据的完整性与可交换性以及字段定义方面来说，著录者对数据库的应用和功能更为重视，这样厚此薄彼的做法直接导致了部分重要字段的丢失，比如审校时间、审校员等管理类型的元数据以及统一资源标识符（简称URI）、资源类型等描述型的元数据；
5）特色数据库元数据中的某些字段内容未达到标准要求，虽然元数据已经有了很长的发展历程，但在近几年才被引入到国内，大部分高校在建设特色数据库的时候它还未被引进，因而过去对其概念的提出并不标准，这就导致各个特色数据库中的字段定义各行其是，没有统一的标准，这些在早期被定义的字段内容取法与现有标准的元数据相契合，例如某一期刊中的年卷期被归纳在一个字段中。
3 特色数据库元数据建立时应注意的问题
3.1元数据的描述深度
所谓元数据的描述深度，就是元数据解释对象的程度的高低，通俗一点来说，就是元数据在定义时的使用数量。在描述对象时，一定要掌握好度，若描述的程度太高，就会增加输入难度；反之，则会导致描述对象数据不完整、对象数据反应不精确等问题。相对于商业数据库而言，特色数据库对元数据的描述程度更高，它的元数据，还包括一些对象数据的输入都要求当地职工完成，所以，如果将元数据定义太广的话，就会成倍增加工作人员的工作量。
对于元数据的要求，读者和著录方的要求有明显的差距。元数据建立的初衷只是使数据更加标准化，方面对数据的检索、管理等，如果仅仅满足于这一要求，那么只需要将主要责任者、正题名、主题等一些重要的元数据进行定义便可。但是，使用数据的主要对象是读者，为了使阅读更加方便，能从更全面的途径检索、获取信息，受众群对元数据的著录提出了更高的要求，他们希望著录的元数据更多更全。面对数据加工和信息服务之间的矛盾，在建立元数据之前应当尽可能地寻求两者之间的平衡点，以求达到最好的效果。
3.2建立非一次文献元数据的标准
现有元数据标准的适用范围十分有限，主要是如期刊单篇、图书、会议论文等的基础文献资料，特色数据库解决了这一问题，它不仅囊括了基础文献资源，还包括一些非一次文献，如文摘等。因此，为了避免建立数据库时做无用功，我们在对文摘等非一次文献数据库著录元数据之前，应当仔细考虑以下问题：是建立基础文献的元数据库，还是建立文摘的数据库？由于两者之间存在很大的差异，所以在工作之前应当搞定这一问题。比如作者，若以文摘为依据，元数据应为文摘员，反之，则为作者；再比如著作时间，以文摘为依据，元数据应为文摘创作时间，反之，则为原文创作时间。就个人而言，在为文摘数据库建立元数据的时候应当以基础文献为依据，原因有二：1）在文摘数据库中有很多像“文摘员”这样的特殊字段完全能够从元数据标准中扩展定义；2）文摘始终来源于文献，它只是对基础文献数据的描述。如果在建立数据库时将文摘作为主要依据，就难以对基础文献进行有效描述，如创作时间、作者等重要信息，这将对作者正确理解文献信息造成障碍。
3.3资源整合模式的运用
资源整合的模式对于元数据的建立十分重要，它能够指明元数据的建立方向。现有的资源整合模式主要有两种：网络模式和独立模式。虽然这两种模式能实现一部分相同的功能，比如跨数据、平台的一站式检索功能，但两者之间还存在着较大的差别。运用网络模式进行资源整合，不会过多考虑文献所属的数据库，而主要考虑数据资源的类型，根据资源属性建立各自的数据库；如果运用独立模式的资源整合模式，就不用考虑资源类型，而按具体标准建立相应地元数据库。相比之下，网络模式的资源整合方式更加适用于元数据的建立，主要原因有三：1）独立模式下的数据库均有它们的元数据库，当数据库达到一定数量时，元数据也会变得十分庞大，这样不仅不利于数据库的管理，还会增加检索的时间，而采用网络模式进行资源整合，就会有基本固定的元数据库数量；2）由于不同数据库之间也存在着相同的资源类型，如期刊单篇同时存在于特色库和CNKI 中，独立模式的资源整合方式会增加各个数据库的元数据，这样不仅使元数据的定义太过随意，还增加了职员的工作量；3）由于元数据的标准需要依据相关的资源类型来建立，所以采用网络模式的资源整合方式更加合理。
4 特色数据库元数据建立的基本原则
作为描述数据的特殊数据，元数据建立的目的就是便于特色资源的检索和存取。通过对特色资源的运行方式、功能特点和系统的总体运行性能进行统一的描述和规定，元数据的建立将特色资源进行标引以方便广大用户的检索与使用。但是，目前首先要进行考虑的特色资源的共享问题，因此，特色数据库元数据的建立应遵循以下原则：
4.1准确性原则
按照元数据的定义，其目的是为了完成对数据内容的描述。因此，准确无误的元数据标引是实现准确描述数据的前提。具体而言，就是要求元数据建立不仅能准确的描述信息资源，还能保证使用的相关术语、元素定义等概念清晰，不存在模棱两可的情况，且不使用那些易于发生歧义的元数据。换句话说，元数据建立时不但要将著录标准、传输语言等进行统一规定，还要对元素的设置、标记语言及著录的原则进行严格的规定。只有实现这样的元数据标引，所建特色数据库的检索质量和检索效率才能达到最好的效果。
4.2标准化原则
在特色数据库的建设时，标准化是实现有效进行信息标引和资源共建共享的主要因素。但目前而言，元数据建立的标准尚存在很多问题。虽然像都柏林核心元素集等流的元数据建立已经有了统一的通用的标准，但是全国各地仍然难以在资源的共建共享上取得统一的认识，在实际操作中仍各行其是，同时在元数据的标引上也难以达成一致。即使是对相同元素进行元数据的著录时，差异往往也会很大。例如，最初像都柏林核心元素集只规定有15种核心集元素，以达到规范、简化元数据的标引过程。但是具体到各地图书馆后，很多图书馆在此基础上盲目扩充，使得该数据集日益复杂化，越来越难以实现标准化了。元数据的标准化内涵广泛，既包括元素著录时内容的标准化、进行相同类型的数字化信息资源的著录时所用元数据的统一性，还包括元数据建立时采用的编码语言的统一化等方面。
4.3互操作性原则
当不同的组织和管理且相关技术规范不完全相同，应该给用户提供统一的检索界面，实现对用户的一致，这就是元数据的互操作性原则。由于组织信息进行特色数据库的建立时，各地图书馆所采用的元数据标准难免会有出入，且学科和内容也有较大差别，数据库建成后又要求实现资源的共享，故应该遵循元数据建立的互操作性原则，以满足客户需求，实现特色数据库的建立。
4.4编码语言的统一性原则
实现对元数据的元素与结构的描述和定义的语法规则和具体语义就是元数据的编码语言。就目前而言，元数据建立时使用的编码语言有很多种，具体包括超文本标记语言（Hypertext Markup Language，HTML）、标准通用标记语言（Standard General Markup Language，SGML）及可扩展标记语言（Extensible Markup Language，XML）这三种。有的元数据对使用何种编码语言有着明确的规定，如美国联邦联邦地理数据委员会、TE1和EAD都只使用SGML语言。有的元数据在这方面又没有相关的规定，如DC数据，既有使用XML的，也有使用HTML的。考虑到资源的共享和数据交换，元数据作为传递计算机系统所能理解的存储数据和信息，其元素结构和组织方式必须要能被计算机理解。但是由于元数据有着不甚规范的编码语言，造成了元数据的格式记录和编码规则不统一，这样的元数据建立的特色数据库就难以实现资源的共享和数据的管理。因此，采用规范、统一的元数据编码语言是实现信息资源的准确描述和资源共享的必然选择。
4.5专用性和通用性原则
元数据建立的专用性指的是某种元数据的建立只能完成一种特定信息资源的描述。而元数据的通用性原则指的是某种元数据可以实现多种信息资源的描述。元数据的专用性适用于对某特定信息资源实现很好的描述，但难以对其他信息资源进行适当的描述；而元数据的通用性原则能实现对多种信息资源的有效描述，却对特定信息资源缺乏足够的描述力度。尽管特色数据库本身是一种专指的数据库，但是作为优秀的特色资源库，其专指的应该是学科，但是该学科所覆盖的内容是可以很广泛的。因此，为实现众多信息资源的有效整合和优秀的特色数据库建设，在进行元数据建立时应兼顾元数据建立的专用性和通用性，在两者间找到平衡，达到更好的效果。
5 结束语
元数据的建立是建设图书馆特色数据库、有效整合和管理信息资源的基础，本文对元数据的基本概念和特点作了较为详细的阐述，其次针对元数据的建立过程中应注意的诸多问题进行了简要分析，最后提出了元数据建立的基本原则。
参考文献
[1]李凌杰.特色数据库建设中的元数据质量控制研究[J].图书情报工作，2010（05）43-46.
[2]袁小一，苏智星.浅谈特色数据库元数据的建立[J].晋图学刊，2005（05）28-30+35.
[3]阴小建.基于XML的特色数据库平台研究[D].山东师范大学，2010.
篇3
由于缺乏统一的组织和管理，相关网络信息的类目设置十分混乱，如类目划分没有遵循合理的标准，划分同一层次时采用2个或2个以上的划分标准，没有应用统一的标准；资源划分时，重复或遗漏现象较多；很多不符合基本逻辑规则的情况，如整体不能包含局部等在网络信息的类目展开中大量存在。基于这些原因，当用户检索时，搜索到的信息就可能与实际需求之间存在很大的偏差。③为了更好的反映动态变化，大多数网站都会设置最新动态和热点专题等类目。尽管这些类目的设置可以更好地帮助用户了解当前最新的信息，但是也会间接的降低信息组织的规律性、逻辑性和层次性，增加网络信息的易逝性，给用户的检索活动带来诸多不便。从当前网络信息资源组织的现状来看，网络信息资源组织者必须通过改进与完善原有的信息资源组织方法，来构建一个更加适合网络环境下信息资源的组织方法。基于这种需求背景，元数据的网络信息资源组织方式产生了。
元数据及元数据方案分析
元数据元数据（Metadata）就是Internet中用于描述数据与资源，促进信息资源组织与发现的数据。关于元数据有以下几点值得注意：（1）元数据不一定是数字形式，它还可能是其他形式，即元数据的形式是多样的。（2）元数据不仅可以用于对信息对象进行描述，同时还可用于对被描述对象的其他情况进行说明。（3）元数据可来自各种不同的资源，除了由人类提供或是计算机自动生成外，通过推断一项资源与另一项资源的关系也可以得到。（4）在信息对象中可以自由增减元数据。元数据方案（1）MARC（机读目录格式）。机读目录格式（Ma－chine-ReadableCatalogingFormat，MARC）是各国信息资源的主要表示形式之一。它提供了一整套完整而详尽的流式数据表示规范，在图书馆书目记录数据应用时，可作为描述、存储、交换、处理和检索信息的基础。经过多年的发展后，MARC已经不仅仅用于描述书目信息，还可用于描述和存取电子信息资源。（2）DC（都柏林核心）。都柏林核心（DC）全称都柏林核心元素集（DublinCoreElementSet），由O－CLC（联机计算机图书馆中心）和NSCA（美国超级计算应用中心）在第一届元数据研讨会上讨论制定的一种元数据格式。DC作为一种元素集，包含了15个基本的数据元素和44个限定词。早期制定DC主要是为了对出版物的信息进行描述，而在随后召开的6次元数据研讨会上，经过不断地补充和修订，DC的结构与功能已逐渐趋于完善。同时，由于它所具有的简单、灵活，易于理解，可扩展性、兼容性强等特点，使得它成为了一个很好的适用于网络信息资源的标识。（3）XML（可扩展标记语言）。可扩展标记语言（ExtensibleMarkupLanguage，XML）从SGML发展而来，是SGML的一个精简子集，既保留了SGML的可扩展性与适用性，同时也支持了灵活多变的Web应用。更为重要的是，它提供了一种对文档进行结构化描述的机制，便于将各种结构的文档作为统一的Web文档的一部分进行传输。由于采用的是结构化的描述方式，因此利用XML便可以在元数据集中定义层次、嵌套结构比较复杂的元素。此外，XML所具有的自己的文件类型（DTD）为在通用的元数据外定义自己的元数据集合提供了便利。（4）RDF（资源描述框架）。资源描述框架（Re－sourceDescriptionFramework，RDF）使用XML语法来表示的资源模型，是一个用于表示Web资源特性及资源与资源之间关系的框架。RDF的提出对解决不同元数据的互操作性与兼容性具有非常大的帮助，同时也为元数据在Web上的应用提供了一种基础结构，使得各应用程序之间可以在Web上进行交换元数据，为促进网络资源的自动化处理提供便利。为了实现元数据标准的统一，国际标准化组织（In－ternationalOrganizationforStandardization，ISO）最近专门成立了一个元数据工作组，用于对元数据全球性标准的研究和建立。这一国际性标准化研究工作组的建立，推动元数据的标准化进程具有十分重要的意义，将使其不断向标准化、结构化方向迈进。随着因特网的不断发展，建立标准的元数据系统已成为人们的共同追求的目标。在这其中，元数据方案的标准化工作已经受到了人们的普遍关注，可以说，元数据的重用与元数据的互换已成为当前和今后元数据发展的必然趋势。
元数据在网络信息资源组织中的作用及应用
元数据在网络信息资源组织中的作用（1）描述。元数据所提供的描述功能就是从元数据的定义出发，对信息对象的内容与位置进行描述，实现对信息对象的存取和利用。（2）定位。一般而言，元数据中都会包含与网络信息资源位置方面相关的信息，利用这些信息就可以准确确定资源的位置，有效地促进信息对象的发现与检索。除此之外，在确定了信息对象的元数据后，对其在数据库及其他集合体中的位置基本上也就可以确定了。（3）搜寻。在著录过程中，可以对信息对象中的重要信息进行组织，赋予其语意，同时建立起联系，保证检索结果更加准确，符合用户需求，为用户提供有价值的识别资源，发现真正需要的资源。（4）评估。元数据所具有的能够提供有关信息对象的名称、内容、时间、格式、作者等信息的功能，使得用户在不对信息对象进行浏览的情况下，就可以对信息对象有一个初步的认识和了解，然后再参照相关的标准，就可以对网络信息资源价值的大小进行评估，并以此来作为存取与利用资源的标准。（5）选择。利用元数据提供的相关信息资源的描述信息，并在参考相应评估标准的情况下，用户就可以非常便利的选择符合自己需求的信息资源加以利用。元数据在网络信息资源组织中的应用元数据及其在XML/RDF结合应用下，可以更好地描述与管理网络信息资源。而在其上的应用技术———推技术（PUSH），则为用户在实际的应用中提供了巨大的便利。推技术是在元数据的基础上产生的，其核心主要是：可以自动搜寻网上信息资源，然后在用户需求的基础上对组织进行加工和管理。目前，在众多针对元数据的研究性工作中，如DC、RDF等的研究，对于推技术而言都是用于实现主动信息服务的基础性研究工作。推技术可直接、全面的表达出用户的信息需求，从而实现了真正意义上的面向用户；信息查询是面向用户、主题的，全部可由用户来进行。将拉技术与推技术有机结合，可以产生多种方式，如先推后拉、先拉后推、推中有拉、拉中有推等，这样不但可以有效减轻带给网络的负担，还可以扩大用户范围，为用户提供更为有效的服务。可以说，它将成为信息系统实现用户主动信息服务发展的一个方向。
篇4
关键词：元数据 电子文件 档案著录
元数据，英文名为 “metadata”，最早出现于计算机信息技术领域，目前已经在多个专业领域，如图书情报、博物馆及档案等领域中得到广泛应用，电子文件管理元数据研究已经成了档案数字化研究中的基础项目。发展中国的数字档案馆不能不对元数据进行研究。
一、档案界关于元数据研究的阶段划分
档案界关于元数据定义的研究起始于20世纪80年代末、90年代初。关于元数据定义的研究目前已经经历了三个发展阶段，第一阶段研究认为在电子文件管理中应有元数据的参与，形成了对元数据引进档案领域后的初始定义；第二阶段是在实践基础上展开了元数据项目研究之后，形成了对元数据的深化认识；第三个阶段则是目前根据元数据在档案界实际应用而形成的对元数据定义的最新成果。
1.第一阶段――元数据的初始定义
元数据是美国著名的电子文件专家戴维・比尔曼首先引进电子文件研究领域的。对其最初的定义是：元数据是关于数据的数据。在这一层面上，元数据的含义与计算机信息技术领域中的元数据的含义是一致的。
然而，这一含义过于抽象、泛指。因为其适用的范围，既可以是档案领域，也可以是其他领域，而且元数据对档案界来说又是一个新出现的术语，在这之前档案工作者还从未遇到过这一术语，所以，元数据这一概念不是很容易被档案工作人员所理解。由于这一原因，在国际档案界，各国电子文件专家、学者又在实践基础上对元数据定义进行了新的探索。
2.第二阶段――著录元数据
由于元数据的含义比较抽象，不直观，不容易被档案工作人员所理解，所以，为了使元数据在档案领域有其更为专指的性质和含义，研究者又提出了著录元数据的概念，即元数据是关于单一电子文件和文件组合的背景及其相互关系的结构化著录数据。其中具有代表性的就是英国公共档案馆《电子文件管理指南(1999)》中所提出的定义：元数据指的是关于某份文件和文件赖以存在的集合体的信息(如它们的背景联系及关系)，泛指结构化的描述和著录数据。①
著录元数据主要指的是著录信息。著录信息是档案界人员所能理解的，而且是早已熟悉的，所以，“元数据是著录信息”的提法比“元数据是关于数据的数据”的提法大大前进了一步。因为，这样就把元数据这一新的术语与传统的档案工作的实践很好地结合起来，并且也有助于实践中对元数据的操作与运用。
在这方面，美国的电子文件专家戴维・沃尔思(David Wallance)于1993年在加拿大《档案》杂志上就撰文指出： 元数据管理就是一个作为目前著录的替代策略而提出来的。原则上，这种方法对档案工作人员不是什么新方法，因为档案工作者早已能获取和利用元数据了。但是，他们以前并没有听说过“元数据”这个词。②
对于这个观点，澳大利亚《工业、研究与教育战略合作元数据项目》的主要负责人苏・麦克密斯（Sue McKemmish）教授在1998年发表的文章中也指出：如果我们以其广义和灵活的方式来考虑元数据，那么档案工作者是元数据的专家，元数据实际就是久以存在于我们周围的一个简单的新词，只不过随着计算机的出现，被赋予了新名称而稍显得不同而已。传统的检索工具、目录卡片、案卷目录、案卷、纸张文件的文头与文尾都包括了元数据。③
但是，如果把元数据定义为著录元数据，容易把元数据等同于传统的著录数据，如《国际标准――档案著录规则(总则)》、《档案机读目录格式》等。但是从当初元数据引进档案界的最直接的动机来看，主要是为解决数字化环境中的电子文件管理问题。所以，如何使元数据与电子文件管理更直接结合起来，就成为档案界所致力探索的领域。
3.第三阶段――电子文件管理元数据
在著录元数据的基础上，国际档案界又提出了电子文件(档案)管理元数据，其真正的含义被定义为：“在对电子文件及其与文件创建和管理有关的人、过程和系统进行确认以及为其提供凭证和背景信息的过程中，有关文件的管理、利用和文件可理解性的元数据。”④“电子文件管理元数据是专门设计用于满足电子文件管理需求，有关保证文件的真实性、可靠性、稳定性、安全性、完整性、可理解性与可利用性的数据。”⑤
由于元数据在电子文件管理中所起的作用和目的性不同于其他用途的元数据，所以，也就把电子文件管理元数据与其他更为泛指的元数据区别开来了，而且也与其他领域中所应用的元数据区别开来了。所以，现在档案界所提出的元数据，已与图书馆界、博物馆界的元数据在内涵与外延上都不尽相同了。
二、档案界关于元数据外延的研究
前面我们讨论与界定了元数据的内涵，那么，元数据所指的外延是什么呢?或者元数据所指的对象有哪些呢?对元数据外延的理解一般可分为三层：
1.单体元数据。即元数据是一个个单独的实体，如表达电子文件的题名、责任者、日期等的元数据。
2.元数据组。即多个具有共同性质的元数据实体的组合。如具有表示电子文件结构这一共同性质的多个元数据实体：MARC、TEI、JPEG、MPEG 等组合在一起，就构成一个元数据组合。由于元数据性质的多样性，所以，同一个元数据同时可以归入多个不同的元数据组合中。
3.元数据系统。即由单体元数据和元数据组所构成的一个有序化的系统。如《电子系统中文件永久性凭证问题的国际研究项目(InterPARES)》的《分析用模板》、美国匹兹堡大学项目的《元数据参考模型》和澳大利亚南威尔士州档案馆制定的《文件管理元数据标准》等均是元数据系统。
三、元数据与著录信息的区别与联系
1.元数据与著录信息的区别
元数据与传统意义上的著录信息是不相同的：
(1)两者的实现目的不同。传统的著录信息的目的主要是用于检索，主要是为实现档案的情报价值而设置的；而元数据主要目的是用于凭证，主要是为实现档案的凭证价值而设置的。
(2)两者的实现方式不同。传统的著录信息的实现方式是“后端控制”，即文件归档而移交至档案馆后才进行著录；而元数据实现方式是“前端控制”，即在文件创建时，就同时对文件进行获取登录。
(3)两者的实现环境不同。传统的著录信息主要实现环境是手工环境，即在手工环境下，对文件进行著录；而元数据实现的环境主要是数字化的系统环境，即在数字化的系统环境中对文件进行控制。
(4)两者实现的过程不同。传统的著录侧重于档案工作过程中某一环节上对著录单位的控制；而元数据的获取登录，则是对电子文件从其产生至结束的整个生命周期的控制。
(5)两者实现手段不同。传统的著录实现手段主要是采用手工著录，即使在制作机读目录的情况下，其著录的过程也是主要靠手工著录完成的；而元数据的获取登录则将元数据系统预设于计算机系统之中，从而使大部分元数据可由计算机系统自动生成。
2.元数据与著录信息的联系
元数据与传统著录信息的联系体现在其个体的共同性上，如反映文件内容的题名、反映责任对象的责任者、反映文件生成时间的日期等，这些个体在元数据中有，在传统的著录信息中也有。这是因为，尽管元数据与著录信息在以上这些方面有区别，但是以上这些方面并没有穷尽它们的所有性质，在除以上这些性质之外，在某些性质上两者又具共同性。所以，研究元数据，我们又不能不注意到传统档案著录信息，寻求它们之间的共性，以实现对传统档案与电子文件在计算机系统中的集成管理。
注释：
① Public Record Office. Management Appraisal and Preservation of Electronic Records
② David Wallance. Metadata and Archival Management of Electronic Records. Archivaria. 1993. 36
③ Sue McKemmish Glenda Acland etc. Describing Records in Context in the Continuum The Australian recordkeeping Metadata Schema. Archivaria. 2000. 48
④ ICA. Guide for Managing Electronic Records from an Archival Perspective. 1997. p20.
篇5
关键词：元数据；异构数据源；XML；信息系统集成
中图分类号：TP311文献标识码：A文章编号：1009-3044(2007)03-10618-02
1 引言
在信息化建设中，许多单位都先后独立开发了信息管理系统。由于这些系统在开发平台、开发工具，开发时间的不同，它们难免会存在逻辑结构、物理结构的不同，即异构性。在实际工作中，往往又需要各个系统的信息之间进行交换、整合、同步等操作来满足业务需求，但是由于系统的异构性，它们之间不能进行简单的信息交换，给实际工作带来诸多不便。因此信息系统集成已经成为当前信息化建设的迫切需求。
本文针对上述问题，把XML作为数据交换的中间文件，提出了一种基于元数据的系统集成的实现方法。
XML（eXtensible Markup Language）可扩展标识语言是W3C组织的XML工作组在1996的SGML（Standard Generalized Markup Language）工作组的基础上创立的，于1998年2月正式推出了XML1.0版本。XML是SGML的一个严格筛选的子集，它既保留了SGML的绝大部分实用的功能，又大大简化了SGML过于复杂的地方，使XML变得功能强大而又易于使用，特别是它的平台无关性，非常适合应用于异构系统集成中的数据交换。
Metadata元数据，通常称为data about data或是data describes otherData。目前，元数据是网络资源组织发展的热点，它与XML的发展密不可分。基于XML的元数据格式将走向标准化，为各种异构系统的集成提供必要的手段。
集成系统采用基于元数据的集成方式。其过程是：系统集成模块接收到查询请求后，对命令进行解析，对照元数据进行语义检查和XML封装，然后将XML格式的查询发送到Wrapper，由之转化分解为相应的SQL查询命令，通过JDBC接口对数据库操作，将返回的数据源查询结果提交回系统集成模块，最后由系统集成模块综合转化后用于用户界面层显示，这样就把已有的多个数据源集成为一个全局管理、采用统一视图、面向用户的集成系统。异构系统对用户而言完全是透明的。
2 集成系统设计
2.1 系统层次结构
基于元数据的异构数据源集成系统如图1所示。最上层是用户层，面向普通用户提供服务，用户输入查询条件，得到查询结果；中间层是系统层，提取用户层的查询条件，返回相应的查询结果，具有查询命令解析、元数据管理和数据综合等功能；最底层的是数据层，包括各种结构化和半结构化的数据，是实际的数据存储地。
图1 异构数据源集成系统层次结构图
2.2 用户界面
用户界面采用JSP动态网页设计，将用户录入的查询条件提交系统集成模块，并将最终的查询结果显示出来。
2.3 系统集成模块
系统集成模块分为命令解析、命令分派、元数据管理、数据综合，数据转换等功能组成，如图2所示。查询命令通过命令解析器的解析后交给命令分派器，命令分派器从元数据库中查阅相关数据源的信息，将查询命令封装为XML发送给指定数据源的Wrapper进行处理。查询的结果或错误信息经Wrapper传回数据综合器。数据综合器从元数据库中读取业务数据之间的关联规则信息，对查询结果进行综合。经过数据转换器格式转换，生成最终的查询结果，以一定的格式呈现给用户界面显示。
元数据是系统集成能否实现的关键。元数据库中主要存放两类元数据：数据源描述和业务数据关联规则。元数据库将这两类元数据集中存放，从而实现集中统一管理。
3 元数据的设计、元数据库的实现途径
3.1 元数据的设计
3.1.1 数据源描述规则部分元数据设计
该部分元数据包括如下部分：
(1)数据源所在机器的IP或机器名；(2)数据库类型及名称；(3)表名、列名及类型；(4)连接条件与筛选条件说明。
其中的表名、列名是Wrapper从数据库中提取的，插入到XML文件的相应部分。文件片段如下：
在一次关于人员和车辆分配的查询中，首先通过查询元数据库中的关联规则人员与车辆的关系，然后查询元数据库中人员库和车辆库的信息，分派查询命令，最后综合就可以给出人员和车辆的分配方案。
以上是部分元数据的设计方法，在集成系统中，对业务数据关联规则采用管理员界面定制，方便动态维护和管理。
3.2 元数据库的实现途径
集成系统中元数据库采用native XML Database数据库Taminoo。Taminoo除了可以存储和访问XML外，还具备多项功能，包括Open Database Connectivity、符合Unicode要求、HTTP通信及处理非XML数据的能力。Taminoo拥有直接XML检索和特殊检索的能力，其查询语言强大而简短，可进入任意深度。
4 集成系统实现
系统采用J2EE技术实现，分别针对管理员界面层、系统集成模块、接口规范定义。其中几个关键技术实现如下。
4.1 元数据管理
元数据管理模块通过发送查询命令给Wrapper，由Wrapper将数据源的元数据信息提供给元数据库，由元数据库进行统一全局管理，从而使多个数据源构成一个统一视图。通过对业务数据关联规则的定制，为查询的结果进行数据综合提供依据。
4.2 模块间接口规范的定义
各个模块间的数据交换用XML的文件格式。进行数据交换时，查询元数据库中相应的信息，按照规则进行数据封装、转换、传输和接收。增加了灵活性和动态适应性。
4.3 Wrapper
Wrapper包括查询语句转换和结果转换功能。查询语句被转换为相应的SQL语句，通过JDBC驱动接口访问具体的数据源。结果转换部分依据查询时建立的XML Schema创造XML元素节点树等，然后将查询结果插入到XML结果文档中，从而实现相应的转换。
5 结束语
本文提出了一种基于元数据的异构数据源的系统集成设计方案，并给出了系统设计和框架结构，对系统实现的关键技术进行了讨论。本系统将为异构的信息系统的集成提供一种解决方案。在本单位的值班系统的信息化改造中，通过对该方案的实施，使单位内各个独立异构的系统有效的集成，提供给用户一个统一的视图，提高了查询效率，达到了预期的目的。
参考文献：
[1]Roth M T, Peter M. Schwarz. Don't Scrap It, Wrap It! A wrapper architecture for legacy data sources[A]. VLDB[C],1997:266-275.
[2]Ullman J D. Principles of database and knowledge-base systems[M]. Vol. II: the New Technologies. Computer Science Press, New York, NY, 1989.
[3]孙君明, 郭红. 基于XML的异构信息交换研究[J]. 计算机应用研究,2003(1):69-73.
[4]沈兆阳. Java与XML数据库整合应用[M]. 北京: 清华大学出版社,2002.
[5]陈传波, 胡书能. 基于J2EE体系的企业数据交换模型研究[J]. 计算机工程,2002,28(4):281-282.
[6]李安渝, 等. Web Services技术与实现[M]. 北京: 国防工业出版社,2003.
[7]李双庆, 游莲, 古平, 等. 一个基于XML的数据交换中间件技术[J]. 计算机科学,2003,30(5):180-181.
篇6
当人类具备了获取海量数据和处理规模化数据的能力时，以大数据应用为特征的信息技术就会走进我们的日常生活与工作之中。自然的、真实的数据能反映出客观规律，是大数据之源；虚假的、杜撰的数据是污染源，必须从各个层面根除。安全生产领域尚没有普遍的、规范的数据源获取体系，因此，必须从数据源建设入手，获取真实的数据。
规范安全监管信息工作体系
安全生产监管监察涉及行业领域多、地域面积广、风险种类复杂、监管体系不完善等，于是长期陷入被动的“治疗急诊”和疲惫的“预防流行”困惑之中。任期压力、任期风险主宰了决策思维，“预防为主、综合治理”便缺乏理性共识，固本强基、长远谋划、共治久安则成为“奢望”。
政策短期化、碎片化导致全系统的基础能力弱化，难以构建系统、完整、明晰的行政监管逻辑关系，安全监管信息化则无源可溯。信息化改变的是服务社会的方式，其价值充分体现在数据的真实性、实时性和集成性，精、准、广是互为制约的三要素。
实现安全监管工作的现代化，既要重视信息化工作平台建设，又要重视新技术集成创新的普及，并且要遵循“由下而上建设，由上而下指导”。边建、边用、边完善，在“用”字上下功夫，力求“好用、管用、实用”。
从安全监管重中之重破题
有效遏制重特大事故是我们必须完成的答卷，解决“查、防、治、救”科学化、信息化、法制化就是重中之重。科学地解决“查什么、怎么查、查哪里？测什么、怎么测、测哪里？治什么、怎么治、治哪里？”，是精准的基础；借助信息技术实现指挥“一盘棋”、决策“一张图”、行动“一张表”，互动“一张网”，是重要的支撑；完善“依法治安”，实现全方位的党纪、法规威慑是重要的保障。
“查、防、治、救”的核心环节是科学建立查的目标、指标、周期、处置等工作体系，至简致用，保障数据源的价值。与时俱进地集成创新测、查等手段，不断提高效能和质量是科研工作的重点。面对多行业、多领域的重大风险源测控需求，四川省安全科学技术研究院于2012年设立了“重大风险源测控四川省重点实验室”，从矿山露天头顶风险源入手，集成高分卫星、三维激光、地下物探三项技术优势，构建了“天空、地表、地下”（三界）多元数据诊断体系，创立了“诊断―分析―设计―治理”（DADT）循环管控模式（见图1），实现了危险源定量化的预测、预警、预防之科学管控目标，全面提升了安全监管监察能力和信息化管控的水平。
全寿命周期的数字化管控
矿山、危化及交通运输等领域普遍存在危险源分布广、点位多、诱发因素复杂及人力难以遍及等共同特点，三界测控技术的处理能力为我们提供了湫碌募际跏侄巍T诨袢〖喙芏韵蠹负纬〖肮丶状态参数的基础上，有针对性地分析并研判风险演化规律，及时制定合理的化解、防范和治理措施。
概括而言，就是通过太空高分卫星周期性获取区域总体数据（m级分辨率）筛查风险，掌握域内风险演变；运用地表三维激光扫描技术，针对已发现并确定的风险实施精准测控（精度mm级），掌握风险具体部位、规模、趋势和系统关联；需要时再运用地下地球物理探测技术（m级分辨率），透过现象看本质，由表及里研判风险诱因（见图2）。
据此，建立由太空、地表、地下“三界”空间测控方法相融合的重大风险源“健康档案”，持续开展稳态数据与实时（或周期性）监测数据智能比对，实现全过程精细化管控，并进行精准预报、预警，针对性地开展防灾减灾设计与综合治理，构建DADT循环管控工作体系，为科学决策和应急处置提供全面的、可靠的数据支持。
篇7
>> 用户数据素养教育视角下的图书馆科学数据管理研究 高校图书馆科研数据管理研究 大数据时代的高校图书馆数据管理研究 元数据在数字图书馆中的应用 国外高校图书馆科学数据的元数据服务研究 元数据在高校图书馆特色数据库建设中的应用与实践 浅谈图书馆元数据的应用 美国高校图书馆的研究数据管理服务体系构建及策略研究 加州数字图书馆数据管理计划工具研究及思考 试论高校图书馆数据管理体系的构建 基于元数据仓储的图书馆信息资源管理研究 元数据及其在数字图书馆中的应用 医院图书馆中文图书数据库管理系统的应用与实践 数据挖掘在图书馆管理上的应用 图书馆信息管理中元数据的应用 大数据在图书馆的应用研究 我国大数据技术应用于图书馆的实践研究 数据挖掘技术在图书馆中的应用 基于数据生命周期的图书馆科学数据服务研究 元数据管理系统的研究与实现 常见问题解答 当前所在位置：.
[12]Data Management Planning[EB/OL].[2014-07-20]..
[13]Khan H， Caruso B， Corson-Rikert J， et al. DataStaR： Using the semantic web approach for data curation[J]. International Journal of Digital Curation，2011，6（2）： 209-221.
[14]Steinhart G. DataStaR： an institutional approach to research data curation[J]. IASSIST Quarterly， 2007， 31（3-4）：34-39.
[15]Bermudez L， Piasecki M. Metadata community profiles for the semantic web[J]. Geoinformatica，2006，10（2）： 159-176.
[16]Lowe B. Datastar： Bridging XML and OWL in science metadata management[M]. // Metadata and Semantic Research. Springer Berlin Heidelberg，2009：141-150.
[17]张晓林. 机构知识库的发展趋势与挑战[J]. 现代图书情报技术， 2014， 30（2）： 1-7.
[18]Dearborn C C， Barton A J， Harmeyer N A. The Purdue University Research Repository： HUBzero customization for dataset publication and digital preservation[J]. OCLC Systems & Services， 2014， 30（1）： 15-27.
[19]殷沈琴，张计龙，张莹，等. 社会科学数据管理服务平台系统选型研究――以复旦大学社会科学数据平台为例[J].图书情报工作，2013，57（19）：92-96.
[20]DataONE[EB/OL].[2014-07-19]..
[29]Keralis S D C. Data curation education： A snapshot[J]. L. Jahnke， A. Asher， & SDC Keralis. The problem of data， 2012： 32-43.
篇8
关键词：网刊系统；元数据；中国知网；VB；自动提取
中图分类号：TP391 文献标识码：A 文章编号：1009-3044（2016）09-0090-03
在国内，绝大部分读者是从期刊网站获取期刊全文，进而进行引用的。因此，期刊建立自己的官方网站，为读者提供论文检索、数据核对、实现在线出版，对扩大期刊的影响力和传播力至关重要[1]。网刊系统为期刊建立一个实现现刊和过刊的浏览、查询等功能的网刊数据提供了技术平台[2-3]。以此为基础，建设期刊自己的网站时，需要对期刊数据进行网刊，对于一般编辑部来说，历史期刊，有的只是纸质的，需要对历史期刊电子化，转化为电子版的期刊还需要进一步进行元数据的提取工作[4-8]。
一般来说，各个编辑部在网刊工作中都是采用手工粘贴拷贝的方式。这种方式不仅工作量很大，而且数据质量很低。另外，由于手工制作的工作量[9]，导致了网站建设要么耗时很长、要么需要大量人力或物力。因此本文基于对象的VB语言编程软件，编写了能够批量提取元数据的程序，采用模式识别智能算法[10-11]，从大型数据库[12]提供的信息中准确提取本期所有文章的元数据，并形成可直接到网刊系统上的Excel文件，大幅度提高工作效率。
5 结束语
在期刊数字化的工作中，对于很多新建网站的杂志社来说，有两部分工作：最新1期的元数据提取；历史期刊的元数据提取。对于很多期刊来说历史期刊的数据都已经不全了，因此通过大型数据库来完善网站的过刊数据成为比较可行的途径之一。通过本文实现的程序可以对1年的过刊数据甚至几十年的过刊数据一次性进行提取操作，工作效率大幅提升。
但是中国知网上的数据更新比杂志社期刊出版要延时约2个月，而且网刊系统中要求有的元数据有32项，而中国知网提供的仅有12项，所以本文方法并不适合使用在最新一期的元数据提取工作上。下一步工作重点研究对最新一期的排版数据进行元数据的提取上。
参考文献：
[1] 闫蓓，严谨，肖宏.搭建科学与大众的桥梁：谈科技期刊与大众媒体的新闻报道合作实践[J].编辑学报， 2009，21（4）： 325-327
[2] 吉玉珠，胡兵.我国学术期刊数字化建设的分析与思考[J].图书与情报，2003（3）：33-35.
[3] 张科，王景发.期刊网络采编系统研发及系统功能分析[J].自动化数字化网络化，2008（4）：72-76.
[4] 洪鸥，姜春明，陈海清.上海市高校科技期刊数字出版现状及分析[J].学报编辑论丛，2011：172-176.
[5] 丁岩，吴惠勤，龙秀芬等.科技期刊数字化出版转型初探[J]. 编辑学报， 2011， 23 （sup1）：3-6.
[6] 林有兴.关于促进科技期刊高效传播科技信息的思考[J].编辑学报， 2005，17（3）： 165-166.
[7] 郑筱梅， 杨小玲. 期刊网络化趋势及科技期刊应对策略[J]. 编辑学报， 2009，21（1）： 64-66.
[8] 孙远，朱晓红，喻伟.网络环境下科技期刊数字化建设初探[J]. 人民长江，2009，40（4）：102-103.
[9] 洪鸥，姜春明，王宁.高校学报自然科学版网络出版现状[J].调查与思考，2014，25（7）：895-901.
[10] 刘晓华.非计算机专业VB程序设计教学探讨[J]. 创新教育，2011（38）：135-137.
篇9
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小结
篇10
关键词：元数据；异构数据库；医疗共享信息；查询系统
中图分类号：TP311 文献标识码：A 文章编号：1006-1959（2017）14-0012-02
随着医疗行业信息化建设推进，各大城市中心医院逐步建立起较成熟的HIS、LIS、PACS、RIS等信息系统。这些系统多为不同的业务系统，都是由不同厂家开发的独立系统，使用的数据库产品不同，具有异构性，而且数据库设计也不同，具有数据异构性，导致同一行政区域的不同医院、不同系统之间数据和资源不能有效共享，医疗数据利用低。通过元数据技术将不同业务系统资源有机整合，以满足对医疗信息共享的需求。
1 元数据概述
元数据是“描述数据的数据”，或者“关于数据的结构化数据”。元数据是用来描述数据本身的内容特征和其它特征的数据[1]。元数据的目标主要有两个方面：①简单高效的描述、保存、组织和管理大量信息资源；②使信息资源的检索、发现、定位和共享更加便利与高效[2]。元数据的基本结构由内容结构、句法结构和语义结构组成。内容结构用于定义元数据的构成元素；句法结构用于定义元数据的格式结构以及如何描述这种结构；语义结构用于定义元素的具体描述方法。
元数据是医疗信息资源组织和处理的基本工具，它为各种形态的医疗数字资源提供了规范、普遍的描述方法，元数据整合中开放描述和互操作性已成为一个基本要求[3]。
2 医疗共享信息查询系统模型
医院的信息系统存在大量异构的数据库，异构性表现在多个方面，如使用不同的数据库产品、数据库表的设计不同、存储的数据类型不同、运行环境不同等。使用元数据技术对异构数据库进行统一规范描述，实现共享访问这些异构数据库的数据。用户通过统一的元数据查询语句完成查询操作，实现数据的透明访问，同时保持了本地数据库的自治性。
区域医疗共享信息查询系统（MQS），采用B/S三层架构，即系统由表现层、业务逻辑层、数据层组成，见图1。
表F层为该查询系统的用户查询接口，提供统一查询界面和显示查询结果。业务逻辑层完成查询请求的处理和查询结果封装，该层由元数据管理模块、转换器、包装器组成。元数据管理模块是系统核心部分，本系统的元数据包括全局数据字典、局部数据字典信息组成，描述最小颗粒为各数据表的字段，并创建描述字段统一的词汇表，以解决数据异构问题。全局数据字典包括查询关键字与局部数据库基本表的映射关系。局部数据字典包括数据库产品名称、访问地址和帐号等信息，以解决异构分布问题。转换器将全局数据库元数据查询逻辑语句进行分解转换，转换为不同异构数据库的查询子语句。包装器将各个数据库的查询结果进行集成处理。数据层是由异构数据库组成，保存大量的医疗数据信息。
数据查询流程如下：用户提交查询请求，转换器从元数据管理模块获取数据库映射关系和元数据信息，将用户提交的元数据逻辑查询语句转换成各异构数据库的查询语句并发送给相应的数据库执行。查询的结果通过包装器进行合并过滤处理并返回给显示界面。
3 系统实现的相关技术
XML技术。可扩展标记语言（XML）是在1998 年由万维网联盟制定的一种源标注语言，主要是为了解决超文本标记语言（HTML） 无法满足越来越多的网络数据交换的需求[4]。使用XML技术可以方便地为数据定义或扩展自定义的描述术语以及这些术语间的结构化关系，良好的自描述性和跨平台特点使其成为元数据非常理想的描述语言。 MQS以查询数据为中心使用XML对系统的全局字典进行描述，部分代码如下：
以上XML代码实现查询关键字“患者姓名”跟数据库的映射，其中属性dbname为异构数据库的名称，tbname表示表的名称，colname表示字段名称，type表示该字段的类型。
DOM文档对象模型是W3C组织推荐的处理可扩展标志语言的标准编程接口[5]。MQS系统使用DOM技术根据用户提交的查询关键字读取解析XML文档，获取异构数据库的元数据信息，再结合局部数据字典元数据生成相应的不同SQL查询语句并执行得到结果。
JSP+Servlet+JavaBean技术。JSP 技术是新一代的脚本技术，能够帮助网页设计和开发人员简单且高效的进行动态网页的开发[6]，JSP动态网页技术实现MQS与用户的交互界面，用于用户查询请求的提交和查询结果的显示，Servlet服务器端程序负责查询请求的任务分发，JavaBean完成业务逻辑处理，包括访问数据库和查询结果的封装。
4 总结
本文提出了一种基于元数据的医疗共享信息查询系统（MQS）解决数据源的异构问题，用户可以通过系统的统一用户接口进行查询，并且从技术的角度分析了系统功能实现的可行性。但并未对异构数据库的元数据提取进行深入探讨，有待进一步完善。
参考文献：
[1]李小涛，胡晓惠，郭晓利.基于元数据的复杂信息共享技术[J].系统工程与电子技术，2015，37（3）：700-706.
[2]赵华，王健.国内外科学数据元数据标准及内容分析[J].情报探索，2015（2）：21-24.
[3]李萍.医疗数据质量的问题探索和解决模式[J].计算机应用与软件，2013，30（8）：217-219
[4]杨旋，朱辰，周小甲，等.基于XML的医院信息集成平台的研究与应用[J].医院数字化，2016， 31（12）：82-85.
