核心元数据

核心元数据（精选10篇）

核心元数据 篇1

一、引言

科研管理信息系统是实现科研组织为管理好本单位科研过程与相关要素的信息系统。近年来,随着技术的不断进步以及科研管理业务的增加,科研管理各级部门已建成了一批具有相当规模的不同资源类型、不同学科的数据库,形成了一个庞大的、分布式的、系统异构的、资源类型多样的数据库群。科研管理信息资源产生于科研机构管理活动的各个环节和部门,信息资源由相关机构分权管理、储存地点分散、搜寻不易,使得对科研管理信息进行综合管理与共享变得十分困难[1]。随着数字科研工程的开展,数字化、电子化和网络化的科研资源信息将会得到迅速地积累和增长。因此,如何充分利用、共享、交换和整合这些海量级、呈爆炸式增长的科研管理信息资源,实现信息资源的共享,依据信息属性对信息资源进行采集、分类、加工处理和存储,实现信息资源的有序组织,使之能更好地服务科研人员、科研过程与科研管理,便成为急需解决的问题。科研管理信息资源的核心元数据的建设是解决上述问题的关键。

元数据(Metadata)是描述其它数据的数据(data about other data),或者说是用于提供某种资源的有关信息的结构数据(structured data)。元数据通常用来描述要素、数据集或数据集系列的内容、覆盖范围、质量、管理方式、数据的所有者、数据的提供方式等有关的信息,是实现数据有效发现、管理、共享、交换和整合的重要手段。元数据的重要作用可以从数据资源和服务两个方面来看。就数据资源而言,科研管理信息资源可以利用元数据标准和技术描述及对外发布其现有的数据资源,提高数据的可用性和被利用率;可以通过元数据记录有关数据的建立、结构以及维护等方面的信息,数据管理者可以通过这些元数据对数据资源进行有效的管理,数据使用者也可据此了解数据资源的一些背景资料;元数据的使用能够在一定程度上消除数据资源之间的语义独立性和异构性,帮助实现数据资源的整合和交换。而服务是向需求对象提供一种或多种价值的功能的活动或行为,它使得数据资源得以被访问、管理和向用户提供增值应用。数据资源元数据和服务元数据两者分别属于不同层面上的元数据规范,但对于数据资源而言,二者可共同为数据资源的充分利用奠定良好的基础。

二、元数据标准及其研究进展

现有的研究中,还没有科研管理信息资源元数据研究,但是已有些相关的元数据标准可以作为借鉴。目前可以用于借鉴的元数据标准主要有都柏林核心元数据标准、中国科学院科学数据库核心元数据标准和政务信息资源目录体系元数据标准[2]。

都柏林核心元数据标准(Dublin Core Metadata Element Set,简称DC)由美国OCLC和NCSA(National Center for Supercomputing Applications)发起,国际性合作项目Dublin Core Metadata Initiative设计,由参与合作项目的机构共同维护修改[3,4]。最初的目的是为了网络资源的著录与发现,由于DC元素简单易用,加之OCLC(Online Computer Library Center)的大力推广,它已发展成为一种可用于描述任何信息资源(“任何具有标识的对象”)的元数据标准。都柏林核心元数据产生于1995年,目前的最新版本为Version 1.1,根据DC1.1版本,DC由15个基本元素构成,这15个元素可分为资源内容描述信息、知识产权描述信息、外部属性描述信息三大类。

中国科学院科学数据库核心元数据标准是由中国科学院计算机网络信息中心制定的用于建设中国科学院科学数据库的核心元数据标准,于2003年5月发布了1.0版本。随后,标准规范工作组对1.0版本进行了修改,形成了标准的1.1版本,并于2003年8月正式发布使用。2004年,标准规范工作组在继续跟踪国际上元数据研究的发展趋势,结合科学数据库核心元数据标准1.1版推广应用的总结和用户的反馈,形成了元数据2.0版。中国科学院科学数据库核心元数据标准主要包含数据集描述信息等七个方面。

政务信息资源目录体系以国家统一的电子政务网络为基础,通过构建覆盖中央、省、市、县的多级政务信息资源目录体系技术总体架构,采用元数据对共享政务信息资源特征进行描述,形成统一规范的目录内容。2007年由中华人民共和国国家质量监督检验检疫总局和中国国家标准化管理委员会联合发布了政务信息资源目录体系核心元数据标准。政务信息资源目录体系核心元数据标准主要包括资源内容描述信息、资源管理信息、资源获取方式信息三个部分[5]。

尽管各组织对元数据的划分有一定的差异,但他们所包含的内容却具有很大的相似性。表1为上述元数据标准内容之间的对比分析,从表1中展示的内容可以看出,虽然几个标准都是从某个方面对数据进行描述,标准之间有者一定的差异,但是都基本涵盖了数据的主要方面[6]。

三、科研管理信息资源核心元数据确定的原则和主要内容

1. 科研管理信息资源核心元数据确定原则

元数据是描述数据集结构化与非结构化数据,是对于信息系统与信息工程以及信息表达对象最深刻最全面理解的体现。而核心元数据又是描述数据集所需的基本元数据的集合。因此,科研管理信息核心元数据的确定需要遵循以下几个原则[7,8]:

(1)实用性。在建设科研管理信息资源目录元数据标准时,既要考虑数据资源单位的数据资源特点以及工作的复杂、难易程度,不能选取太多我元数据元素,过于复杂不便实际使用;又要充分满足工程建设以及用户的需要,不能过于简单。在复杂与简单之间取得平衡,才能不能真正满足各种用户的需求,同时实现共享系统的最大效益。

(2)准确性。科研管理信息内容涉及到人力资源、科研项目、综合财务、科研条件、国际合作、院地合作、知识产权、评估评价、基本建设等内容。因此,在确定核心元数据内容时,需要准确而简洁地将科研管理信息资源数据集主要特征的数据整合起来。

(3)结构性。由于核心元数据内容存在着复杂的逻辑结构关系,因此,需要用模型表示其中的逻辑关系,以便对核心元数据进行修改或扩展时不破坏整体结构,并且作为核心元数据实现的概念模型[3]。

(4)一致性。由于元数据是对其他标准的高度概括,在建设元数据时,应参考相关领域现有的国际标准与国家、行业标准,尽量采用国内外先进标准。

(5)前瞻性。标准不但要满足现阶段科学数据共享建设的标准化需求,更应该考虑将来一定时间内由于科技发展等原因可能产生的标准化需求,这样制定出的标准才会更有生命力。

2. 科研管理信息资源核心元数据主要内容

科研管理信息资源核心元数据内容是主要以都柏林核心元数据DC(Dublin Core)和《中国科学院科学数据库核心元数据标准2.0》为标准,并扩展少量具有科研管理信息资源目录特色的元素,对科研管理信息资源的每一条记录进行描述,形成科研管理信息资源目录核心元数据标准。

科研管理信息核心元数据主体包括描述信息、元数据参考信息二个主要复合元素模块,且二者均为必选模块。此外,还包括联系信息一个辅助模块,此模块不可单独使用,供其它模块的特定元素在需要的时候进行引用。

(1)描述信息。描述信息模块是记录数据集基本信息模块,是一个必选模块。通过使用描述信息模块,建设单位可以对数据集的基本属性信息进行详细描述,例如数据集名称、简介、创建者、来源等,数据集用户可通过浏览这些描述信息对数据集形成一个总体了解。

(2)元数据参考信息。元数据参考信息模块是关于数据集元数据本身状态的信息,为必选模块,包括元数据标准名称、元数据创建日期、元数据联系信息等内容。通过该模块,一方面,数据集用户可以了解到与元数据记录的建立有关的信息,另一方面,元数据参考信息将有助于元数据维护人员进行元数据的修改与维护。

(3)联系信息。联系信息模块记录与数据集有关的联系信息。该模块不可单独使用,而是被主要模块的有关元素引用。

四、科研管理信息资源核心元数据的设计方法和框架结构

科研管理信息资源核心元数据的建设,主要是为了对已有信息资源进行规范和重新组织,实现信息资源的共享,通常是用在科研管理信息资源管理平台中。元数据作为科研管理信息平台的重要组成部分,起到规范整理资源的作用。

1. 元数据在平台中工作流程

科研管理信息资源平台的系统工作流程为:数据提供者向科研管理信息资源库提供数据,再根据元数据标准提取元数据,并进行分类,再把元数据注册到元数据注册管理系统,存入科研管理信息资源元数据库中。使用者通过元数据目录服务系统进行查询,获取所需科研管理信息资源相关数据。系统工作流程如图1所示。

2. 科研管理信息资源核心元数据工作原理

数据从数据源到数据仓库的过程中需要经过ETL(抽取、转换、加载)操作,在数据仓库之中数据得到集成,从数据仓库到数据集市的过程中也需要进行相应的ETL操作,从数据集市到数据报表实际上是为服务提供数据。在这个数据集成的过程中,数据需要进过不同的数据源、ETL操作、数据表格的存储(Database tables)以及数据中心所能提供的服务,而这一切都需要元数据进行描述,在数据仓库之中需要建立元数据信息库(Metadata Repository)对数据集成的整个流程进行管理。元数据工作原理如图2所示。

3. 科研管理信息资源核心元数据工作流程

元数据制定与使用分为三个层次,首先,元数据开发人员根据都柏林核心元数据DC(Dublin Core)和《中国科学院科学数据库核心元数据标准2.0》,建设科研管理信息目录体系核心元数据,产生元数据标准;然后,编目员把元数据标准应用到科研管理信息资源,产生元数据记录;最后,用户利用元数据记录发现科研管理信息资源。元数据工作流程如图3所示。

五、结语

科研管理信息资源元数据标准是对分散的科研管理信息资源进行整理的重要工具,在科研管理需求的信息资源的基础上,通过遵循统一的元数据标准规范,对已有信息资源进行规范和重新组织,实现信息资源的共享,最终满足用户在大量科研管理信息资源中准确、全面、迅速、方便、经济地获取所需信息内容的各种要求,是科研信息资源管理的重要目标。本文在都柏林核心元数据标准、中国科学院科学数据库核心元数据标准和政务信息资源目录体系元数据标准基础上,结合科研管理信息资源的特点,整理出科研管理信息资源核心元数据主要内容,并分析了其在科研信息资源管理平台中的作用以及其工作流程,为有效管理各类信息资源提供重要参考。

摘要：随着信息技术的不断发展,科研管理信息系统已经实现了业务的信息化。然而这些系统无法进行信息交流,导致了“信息孤岛”的现象。业务间关联使得科研管理需要进行数据交换,因此有效解决数据集成问题具有重要的现实意义。而元数据中包含的数据结构和语义说明信息是数据集成的重要信息,因此元数据建设是数据集成关键技术。本文以都柏林核心元数据DC(Dublin Cord)、中国科学院科学数据库核心元数据标准2.0和政务信息资源目录体系为主要参考依据,结合科研管理信息资源的特点,研究确定了科研管理信息资源核心元数据主要内容,并分析了其在科研信息资源管理平台中的作用以及其工作流程。

关键词：科研管理信息,数据仓库,元数据

参考文献

[1]胡永健,周寄中.科技资源信息元数据质量审核方法研究[J].管理评论,2011,(23):41～47.

[2]吴显义.我国元数据研究现状分析[J].情报科学,2004,(22):4～7.

[3]吴建中.DC元数据[M].上海:上海科学技术文献出版社,2000.

[4]Guimaraes,T.Information Resources Management:Improving the Focus[J].Information Resource Management Journal,1998,DOI:10.4018/irmj.1988100102.

[5]李霖,郭仁忠,桂胜.电子政务信息资源目录体系建设及案例[M].北京:科学出版社,2009.

[6]刘嘉.元数据:理念与应用[J].中国图书馆学报,2001,(5):32～36.

[7]Fox,C.,Levitin,A.and Redman,T.The Notion of Data and its Quality Dimensions[J].Information Processing and Management,1994,(30):9～19.

[8]姚艳敏.国土资源信息核心元数据的研究[J].测绘学报,2001,(4):349～354.

核心元数据 篇2

DC元数据方案是一个非常灵活且及具扩充性的方案，然而对于各馆合作的同一个项目，原则上应该制订一些 统一规则，例如元数据元素的增删取舍以及限定方式等，当然也可以由各馆自定，这样会在一定程度上影响到互操作性。制订统一规则的难点是必须经过各馆统一一 致的详细讨论，这是一项耗时费力的工作，必须由项目组负责协调组织。

首先必须说明的是，根据项目技术组的结论：

DC只是提供互交换性的中间层，虽然是必需的，但不一定要物理存在，物理层为第二层即MARC或TEI Header，通过自动转换动态获得，或重新抽取均可；

元数据的表达只有在HTML4.0及XML中才能采用RDF方式实现，鉴于目前HTML3.2普遍采用，本项目完成时前者也不一定能完全取代后者，据此本实施意见仍旧考虑了在HTML3.2中利用“META”方式表达元数据元素的方法；

本文涉及许多规则，如DC、RDF等，至今仍然是草案，尚处在不断的变动中，未承诺任何版本兼容性，是否能够得到广泛支持尚不得而知；

本文作为本项目工作小组的研究报告，根据以上会议精神，将对项目元数据方案进行进一步的描述和限定，为便于实际实施，特进行实例描述。

目录

一、DC元素定义及其限定

二、RDF框架及其含义

三、实施实例及说明 DC在HTML2.0/3.2中的应用

DC在HTML4.0中的应用

DC的扩展应用

RDF与DC的应用

四、实施建议

一、DC元素定义及其限定

关于DC的历史影响、结构框架以及为何选用DC作为最小元数据集合的原因本文不再赘述，请参见文末所附的参考资料：

下文给出DC十五个元素的中文基本定义，原文定义请参见其主页： http://purl.org/metadata/dublin_ core。

DC元素基本描述

以下是对DC元数据元素集的参考定义，关于进一步的描述或任何已经定义的限定，请见下列地址： http://purl.org/metadata/dublin_core。在以下的描述中，为便于进行语义上的理解，每个元素都有一个描述性的名称，同时为便于在一定的编码体系中使用，每个元素都有一个正式的标签(Label)。尽管HTML之类的环境并不区分大小写，我们还是建议在实际使用中按照下文所定义的标签大小写来进行书写，以免在转换或移植到其它环境时发生冲突或歧义，如在XML中。（参见 http://中嵌入上述代码特别有用，因为在非缩写格式中，”上海科文工作室”将被作为显示字符析出，而在缩写格式中则无这样的问题。同样例五中的描述可缩写成如下格式： CARD:Name=”John Smith” CARD:Email=”smith@home.net” CARD:Affiliation=”Home, Inc.” />

四、实施建议(未完成)实施建议如下：

首先我们认为在语法结构，使用惯例上没有必要将DC进行中文化处理，而沿用国际通用的英文描述方法。对DC的基本定义也没有必要进行重新修订，以利于信息与国际上的交流。以DC为基本框架

以HTML2.0/3.2格式为主

核心元数据 篇3

关键词: 元数据 数据服务 按需共享 XML Schema

中图分类号: TP39 文献标识码: A文章编号: 1007-3973 (2010) 04-051-02

1 引言

随着计算机软件技术和网络技术的快速发展,以及计算机应用需求的不断增强,现代企业的日常业务通常都是由众多以网络为中心的应用系统完成,每个应用系统都有具体的任务职责。通过使用这些应用系统,达到了降低管理成本,规范业务流程和提高服务质量的目的。随着信息化建设的深入,可利用信息源数目的不断增大,人们对于存取、关联、组合多信息源信息的愿望越来越强烈。因此,数据的开放式共享是网络时代的必然需求。

数据共享自被提出以来就引起了国内外众多科研人员的关注,已成为当前重要的研究方向。实现数据共享的核心就是解决数据源的数据量大;异构性强;数据格式多样;动态变化和分布;自治程度高等问题。以网络中心的信息共享的目标是确保所有的数据都是可见的、可理解的、可获取的和可利用的。

元数据通常被定义为“数据的数据”,其作用为:描述信息资源或数据本身的特征和属性,规定数字化信息的组织,具有定位、发现、证明、评估、选择等功能。目前元数据已经从简单的描述或索引发展成为用于管理数据、发现数据、使用数据的一种重要工具。因此,元数据是数据共享的重要基础。

数据服务可认为是提供给用户访问一些结构化和半结构化数据的功能组件。数据资源拥有者把数据的各种操作以服务的方式封装,发布在互联网上,供其他用户使用。其他用户不必关心共享数据存储在什么地方和存储的方式,数据对用户而言完全是透明的。

本文探讨元数据技术和服务技术在数据共享中的应用。

2数据共享总体框架

图1为基于元数据的数据共享的基本原理图。如图所示,系统可以划分为三层结构:应用层、数据服务层和数据层。应用层与数据服务层之间采用SOAP协议进行通信。其中,数据服务层是整个数据共享系统框架的核心层,它是应用层与数据层之间关于数据的抽象,以服务的方式抽象出关于底层数据源的各种操作,对外提供共享能力。从用户的角度来看,他只关心服务提供的能力,而不关心服务的具体实现,减少了程序人员学习不同数据库所消耗的精力。

图1 系统层次结构

2.1数据封装器

数据封装器位于数据源之上,它是整个共享模型中最重要的部分,将分散在各处需要共享的数据源按照我们统一的数据模型进行封装。XML Schema文件为XML文件数据类型建模提供严格而完整的标准。我们可以利用这一特性使用XML Schema文件来建模数据库表的结构和内容,以及约束条件。数据封装器使用XML Schema文件对用户所要共享的数据库信息进行建模,使用XML文件来描述数据库的基本信息(数据库类型,用户名,密码等等)和数据库表之间的逻辑关系,把所共享数据的元数据信息提交到元数据中心,完成封装和共享功能。

2.2 中介(mediation)服务

不同的数据源之间存在异构性,特别是语义上的异构性,例如不同字段上的同一名称可能代表着不同的含义,这种异构性给数据共享带来了麻烦。中介服务提供一种格式转换功能,利用存储在元数据中心的各领域的元数据标准,把异构的数据映射到一个同构的虚拟视图上。

2.3 服务封装

服务封装的功能是对共享数据的各种操作以服务的方式进行封装,对外提供数据共享能力。

2.4 元数据中心

元数据中心在数据共享系统中的作用是提供一个元数据信息的共享空间,存储着各种元数据信息,对外提供元数据注册、查询和管理功能。元数据信息包括共享数据资源的元数据,发现类元数据,不同领域的元数据标准等等。用户通过提交共享数据的元数据信息到元数据中心实现资源共享,以及参考领域内的元数据标准开发应用系统,统一数据视图,实现系统间数据的互通和互理解。

2.5 数据服务中心

数据服务中心管理着用户发布出来的数据服务,提供注册、管理和查询数据服务的功能。决定数据共享能力的关键点并不是采用何种技术对数据进行封装和共享,而是在大量的资源中满足用户快速和准确的找到资源的需求。数据服务中心采用定制的发现类元数据对数据服务资源进行描述,提升资源的发现能力。

3 关键技术研究

3.1 数据封装器

目前,数据封装器主要封装一些结构化数据,例如数据库信息。本文提出的数据共享系统对数据源的共享粒度细化到数据表级,而不是数据源级。因此,易于形成高内聚低耦合的状态,实现新加载数据源的按需共享和快速共享。用户根据需要对部分数据库表进行封装和共享,而不是为了共享某些数据而把整个数据库共享出去,实现了按需共享的目标。

数据封装器使用XML Schema文件来描述数据库表的结构和内容。下面举例说明如何使用XML Schema文件对数据库进行建模。例如,一个数据库表包含字段title, author, price, resume, recommendation,类型都为string型。用于封装该库表的XML Schema文件为:

其中可以在每一个element属性下面添加用于解释该字段含义的注释。例如:

书籍的标题名称

3.2 元数据抽取器

元数据信息抽取器属于元数据中心的功能模块,其功能是解析用户提交的共享数据的元数据文件(包括XMLSchema文件和XML文件),并提取文件内的元数据信息,存储到元数据中心。提取的元数据信息的最小粒度为数据库表的字段名和该字段的注释,也就是Schema文件内element属性下的内容。用户在元数据中心不但可以搜索到需要的共享数据,甚至能够了解到共享数据库表内字段的约束和具体含义。

3.3 发现类元数据

发现类元数据标准是一组与每个数据资源相关的通用描述性元数据要素,以支持利用搜索工具发现数据资源。如图2所示,发现类元数据采用分层方法设计,由一个“核心层”和一个“扩展层”组成。 核心层包括4个要素类别组,分别为安全目录集、资源目录集、摘要内容目录集和格式目录集合,每组都有一个描述数据资源的特殊功能重点。扩展层则是根据领域特性增加的一些元数据要素。

用户在发现类元数据目录中输入所感兴趣的核心要素,利用发现类元数据发现资源的能力在共享空间中搜索共享资源,准确地找到所需要的相关数据资源。

图2 发现类元数据逻辑模型

4 总结

本文提出了一种结合元数据技术和服务技术的数据共享方案,并给出了系统设计框架,特别是给出了数据包装器的设计说明。该数据共享设计框架具有以下特点:

(1)按需共享。数据存储在本地,按照需求有选择性的共享数据,提高了数据的安全性。

(2)透明访问。不必关心数据存放的位置和存储的方式,只需要调用数据服务就可以使用共享数据,对用户而言数据是透明的。

(3)松耦合。数据的请求者和提供者之间只有接口上的往来,移除请求者和提供者之间的依赖性。数据源的替换或者更新都与数据请求者无关。

参考文献:

[1] 李军怀, 周明全, 等. XML在异构数据集成中的应用研究[J]. 计算机应用, 2002, (9).

[2] 李学荣, 李莎. 基于元数据的异构数据源集成系统设计与实现[J]. 计算机应用,2005, (25).

[3] 丁兆青, 董传良. 基于 SOA 的分布式应用集成研究[J]. 计算机工程,2007, 33(10).

[4] 毛新生.SOA原理??方法??实践[M]. 北京:电子工业出版社,2007.

核心元数据 篇4

开展全国国土资源“一张图”建设, 形成国土资源核心数据库, 是落实中央领导、部领导和全国国土资源信息化工作会议精神的重要行动和步骤, 是要解决当前国土资源数据汇交、采集、更新、积累、整合、开发、利用尚不能满足国土资源监测监管和社会化服务需求的信息化瓶颈问题。

南京市“一张图”的建设主要围绕3个重点展开。一是多源数据的整合, 主要解决过去国土资源“多张图”的问题, 改变各部门之间相对独立、存在数据孤岛的情况, 从而实现“一张图”统一管理。二是注重集成、面向服务和监管, 基于统一的地理空间框架, 面向国土资源监管和服务目标, 集成管理基础地理、土地资源、矿产资源和地质环境等各种数据集。三是注重数据联动, “一张图”的各种数据不是简单的叠加, 而是通过搭建基于“一张图”核心数据库的业务管理系统。根据业务内在联系, 实现关联和联动, 通过关联数据的展示反映业务的内在联系。

如何充分发挥数据在国土资源形势分析、资源监测监管、地质灾害防治、宏观调控、辅助决策支持及社会化服务中的作用, 这是国土资源信息化建设的核心任务之一, 对国土资源管理工作和社会服务具有重大和全局的意义。建立1个集中管理、安全规范、充分共享、全面服务的核心数据库势在必行。文章以南京市为例, 研究“一张图”核心数据库的建设和管理问题, 通过分析国土资源数据、元数据及其在数据管理中发挥的作用等, 设计元数据结构, 提出基于元数据的“一张图”核心数据库建设管理。

1 国土资源数据现状分析

国土资源数据一般来源于国土、规划、测绘等部门, 且数据格式、坐标系、数据精度、空间尺度、时间尺度、数据标准等也各不相同。从数据使用的角度讲, 数据种类繁杂。比如:依数据种类划分, 国土资源“一张图”数据库主要包括空间数据和非空间数据。其中, 空间数据包括矢量数据和栅格数据;非空间数据包括业务指标、表格、文档、报表、附件等数据。依数据用途划分, 又主要包括基础数据和专题数据。其中, 基础数据主要是遥感影像数据、城镇地籍数据、土地利用现状数据和土地利用规划数据;专题数据主要包括建设项目用地数据、土地供应数据、土地开发整理数据、土地执法监察数据、土地储备数据、基本农田数据、基准地价数据、农用地分等定级数据、矿业权数据、矿产资源规划数据、地质灾害数据等其他专题数据。这种数据状况导致信息孤岛无法破除, 限制了国土资源管理中数据的挖掘和综合利用, 制约了国土资源数据的共享和服务。

总之, “一张图”核心数据库包含的数据内容丰富、来源多样, 数据标准、模型、格式、精度、存储形态等差异很大, 要将种类繁多、数据量巨大的各类土地、地质、矿产数据库集成整合为支撑国土资源监管和管理行为的核心数据库, 需要按照统一的标准规范开展数据整合和数据整理工作。

2 元数据

元数据, 即数据的数据, 主要是描述数据的内容、质量、数据源、基础结构等。国际上针对不同应用领域制定了很多元数据标准, 其中地理信息领域也有很多元数据的标准, 如FGDC (美国联邦地理数据委员会) 、ISO (国际标准化组织) 、OPEN GIS (开源GIS协会) 、国家基础地理信息各自都制定了地理空间元数据内容标准。这些标准基本上都对元数据的定义、相关术语、层次结构、性质、元数据内容、空间参照系统、标识信息等方面做了标准化描述。

信息化高速发展的时代, 元数据已经由一种描述与索引的方法扩展到包括数据发现、数据转换、数据管理和数据使用的整个数据共享使用过程中的工具和支撑之一。在数据管理与共享中, 元数据发挥的作用也更为重要。例如:城市公共信息平台建设中也规范了相应的元数据标准, 通过研究其元数据要求, 比较研究地理信息其他应用中的元数据使用。概括总结元数据在地理信息数据管理与共享中发挥的作用如下:

数据发现阶段, 通过元数据定位和理解数据, 并对其进行查询、浏览、分析。

数据转换阶段, 通过元数据掌握其格式、空间参考、文件大小等信息, 指引和控制数据转换工作的思路和方法。

数据管理阶段, 通过元数据掌握数据的来源、状况、质量、内容等。基于元数据组织数据库, 可以有效降低数据存贮的空间, 减少数据用户查询数据库及获取数据的时间, 从而降低数据库的建设使用和管理维护费用。

数据服务阶段, 通过元数据掌握数据的适用范围和适用对象等, 控制数据的共享、使用和安全。同时基于元数据借助XML等可提高数据交互服务的效率, 节约时间、降低数据共享服务成本。

3 南京市“一张图”核心数据库建设

3.1 框架设计

通过对南京市国土资源数据的整理和归类, 南京市国土资源“一张图”核心数据库从逻辑上划分为基础层、专业层、管理层。其中, 基础层通常作为底图数据使用, 更新频率较低、周期较长, 如基础地理数据、遥感影像、地形图;专业层是由土地、矿产、规划等业务部门调查规划产生的数据, 具有内容种类繁多、多尺度、专业性强等特点, 包括土地利用专题 (土地利用现状数据、基本农田数据) 、土地规划专题、矿产资源专题、地质环境专题等;管理层是在土地、矿产资源等管理过程中产生的数据, 具有伴随管理业务实时更新的特点, 包括征供地数据、执法巡查、土地整治等。

同时, 在全面梳理部、省、市相关数据库建库标准和规范, 并参考《全国一张图核心数据库建设方案》的基础上, 结合南京市实际情况, 相关部门制订南京市“一张图”数据库建设方案和覆盖南京市国土资源数据的4个大类、21个小类、50余个数据集的数据库结构。下一步是需要厘清“一张图”核心数据库框架结构 (见图1) 。

元数据由1个或多个元数据子集构成, 包含1个或多个元数据实体。综合分析南京市国土资源管理数据的特点, 定义元数据实体是下列实体的聚集, 分别为:基本信息、质量信息、更新信息、来源信息、覆盖范围信息、分发信息、流转信息、元数据扩展信息。

具体描述数据的如下信息: (1) 基本信息。描述数据的文件名称、数据格式、大小、空间参照系统、比例尺、成图时间、保密级别以及简单的内容提要。 (2) 质量信息。描述数据生产参照的质量标准或规范、质量等级、质检单位、质检人员。 (3) 更新信息。包括更新时间、更新单位、版本、更新内容、更新说明。 (4) 来源信息。来源单位或部门、来源负责人、来源人联系方式、来源格式、来源空间参照系统、接收信息 (接收人、联系方式、接收时间) 。 (5) 覆盖范围信息。描述实体的时间范围、空间范围。 (6) 分发信息。描述可使用者 (使用人名称、所在单位部门、岗位名称) 、操作权限、使用期限、使用者责任等信息。 (7) 流转信息。主要是针对管理数据, 描述其在审批流程中产生的元数据内容, 包括创建时间、所在业务节点、时间节点、办理人、办理状态、结束时间、成果类型、事宜认定。 (8) 元数据扩展信息。考虑到日后的元数据管理需要, 特设元数据扩展信息, 待需要时补充描述。

3.2 管理模式

南京市国土资源“一张图”数据以“集中统管, 分权使用”思想为指导, 元数据贯穿数据的整个生命周期, 市局采用Oracle11g集中存储各类空间、非空间数据, 矢量、栅格数据, 并以数据服务的形式、分权提供给市、区县、国土所3级使用。如图2, 数据管理和元数据管理同为“一张图”核心数据库的管理的重要部分, 数据编辑、更新、入库, 每一个环节牵制着元数据的录入、更新和扩展;同时数据服务阶段, 数据分发与展示也离不开元数据的查询、分析的支撑, 进而提高数据服务的准确性和效率。下一步是需要厘清“一张图”核心数据库管理模式 (见图2) 。

3.2.1 数据存储管理

根据前期的元数据设计, 国土资源“一张图”数据集中存储于“一张图”数据库中, 构建实体元数据, 不同的数据实体分用户集中统管。用户根据权限可以对数据进行编辑、入库、更新操作, 同时, 数据实体相应的元数据录入数据库;用户也可通过元数据查询、分析快速获取定位自己需要的数据, 实现元数据表和实体数据同步维护、关联分析。

从数据入库、编辑更新、查询分析, 到数据分发使用, 元数据贯穿数据的整个生命周期。元数据不再仅仅是对数据描述的数据, 更是管理数据的得力助手、获取数据的高效途径, 为依托“一张图”进行国土资源管理, 实现国土资源数据切实整合、高效利用, 提供了数据保障。

“一张图”平台支持元数据的入库, 维护元数据与数据的关联, 可对元数据进行浏览查询, 进行查询和统计汇总, 在数据经历重要处理时追加或更新相关元数据信息, 可实现元数据的输出与打印。下一步是需要厘清“一张图”平台元数据查询页面 (见图3) 。

3.2.2 数据服务管理

国土资源数据使用中, 市、区县、国土所3级可访问的空间范围不同, 不同部门处室对数据的需求各不相同, 不同的访问者对数据的操作权限也不同。因此, 在数据服务管理时, 基于“分权使用”的思想, 根据元数据过滤数据、限制权限, 把正确的、合理的数据提供给相应权责的用户。图4是为南京市国土资源“一张图”基础数据服务平台中受控于元数据分发信息的“角色—权利”形式的数据分权使用管理的界面。下一步是需要厘清“一张图”数据服务分权管理 (见图4) 。

4 结语

元数据自身的特点决定了其在“一张图”核心数据库建设、管理中不可或缺的地位。南京市基于元数据成功构建了涵盖城乡范围、空间及非空间数据、区分基础、专题等数据种类的国土资源“一张图”数据库, 准确反映国土资源业务数据之间的关联关系, 为管理者对国土资源“总量、结构、布局和时序”的全面掌握提供准确、全面的数据支撑。今后的研究和实践还需进一步完善现有元数据结构, 提高国土资源行业对元数据的应用分析能力和管理能力。

参考文献

[1]李军.地球空间元数据的使用研究[J].地球信息科学, 2000 (3) :8-12.

[2]辜寄蓉, 苗放, 王成善.基于元数据的信息共享机制研究[J].物探化探计算技术, 2006 (1) :75-79.

核心元数据 篇5

关键词：档案； 元数据； 电子文件； 保管期限； 自动鉴定

1 电子文件鉴定研究综述

随着电子文件的出现及其对传统纸质档案鉴定理论的冲击，国内外许多学者对电子文件的鉴定理论进行了研究。刘越南认为电子文件自动鉴定的方法是在系统中纳入并维护电子文件保管期限表。[1]于慧敏提出可以根据机关或部门的职能重要程度编写程序由系统自动鉴定，自动给文件保管期限。[2]谭琤培和章丹指出要建立元数据系统与制定元数据标准，通过系统自动记录与手工记录获取档案元数据。[3]由于电子文件的迅速增长，关于电子文件鉴定的迫切性在业内已经达成了共识，而大家期盼的最理想的目标是对电子文件实行自动鉴定。从综述看现有的理论研究并未达成共识，没有形成电子文件自动鉴定相对成熟的理论体系，需要相关研究不断地总结与完善。目前的研究成果大都集中在电子文件鉴定内容、程序、方法、原则等宏观方面的研究，缺乏微观方面的研究。

对电子文件的鉴定主要包括价值鉴定和保管期限的鉴定。价值鉴定十分复杂，需要考虑的内容很多，而且容易受鉴定者的主观影响，因此本文对价值鉴定不做过多的阐述。档案的鉴定同样可以通过保管期限来完成，在实际鉴定保管期限时，目前还是参照国家档案局出台的文书档案保管期限表进行判断，由于保管期限表条款划分过粗、加之人为的因素或者判断标准不统一的情况，使得电子文件的保管期限判断不够准确。笔者试图从电子文件的部分元数据内容入手来判断电子文件的保管期限。

本文以元数据为切入点，主要采用在文献调查的基础上，通过统计方法构建元数据库，将元数据内容信息作为电子文件保管期限自动鉴定的依据。笔者通过选取文件标题、主题词这两个能反映文件全貌的元数据内容项目进行了实证分析，对自动鉴定结果进行了验证。

2 电子文件元数据库的内容创建

元数据是指描述文件背景、内容、结构及其整个管理过程的数据。档案元数据描述的内容有以下三方面：（1）内容信息：如标题、档号、分类号、主题词等；（2）结构信息：如段落层次、文体、发（收）文者等；（3）背景信息：如形成文件的机构及其职能、业务活动等。[4]通过观察，档案元数据描述的内容中除了文件标题和主题词能反映文件全貌，其他元数据项目难以用来判断一份文件的保管期限。因此本文只选用了文件标题和主题词这两个项目来判断一份电子文件的保管期限。适当的情况下，在判断保管期限时，还可以加入责任者项目。

为了使电子文件自动鉴定具有可操作性，笔者根据国家档案局发布的第10号令《企业文件材料归档范围和档案保管期限规定》，将其中涉及的元数据内容抽取出来，该元数据库要嵌入档案管理系统自动鉴定模块中。部分元数据库如表1所示：

表格说明：

（1）一级标识限定了电子文件的内容方向，二、三、四级标识隶属于一级标识，只有同时满足一级标识、二级标识、三级标识或四级标识才能判断某份电子文件的保管期限。

（2）由于政策的变化，长期、短期、永久划分没有绝对的标准，各单位依据自身具体情况，参照国家档案局出台的保管期限划分等相关规定进行区分，短期可能是3年、5年、10年或15年不等，长期可能是15年或30年不等。

3 电子文件自动鉴定规则、流程与实例

3.1 电子文件自动鉴定规则。要使电子文件实现自动鉴定，只有元数据库是不够的，还需要一些规则对其进行规约，笔者归纳出以下鉴定规则：

3.1.1 元数据库中的元数据项目彼此之间存在从属或并列的关系，因此在设计数据库的时候，要把元数据项目之间的这种关系表达清楚，能提高自动鉴定的准确度。如下所示：

1党政企事业单位设立、变更、解散

1.1筹办申请、设立申请、批准设立永久

表中内容是永久元数据库中的项目，一级标识是代表党政企事业单位在设立、变更或解散过程中形成的文件材料；二级标识是代表在满足一级标题的情况下，如果涉及筹办申请、设立申请和批准设立的文件要永久保存。每一级标识里的元数据之间是并列的关系，而上一级标识和下一级标识之间是从属的关系。

3.1.2 当判断一份归档文件的保管期限时，系统自动从档案著录系统中提取专业人员拟定的主题词、文件标题等元数据，然后与元数据库进行匹配，可以设置精确匹配、模糊匹配、前向匹配等多种匹配方法。

3.1.3 当抽取的电子文件元数据与元数据库进行匹配时，匹配的内容之间可能存在同一关系、同涵关系、包含关系、参照关系。因此从电子文件中抽取元数据的时候要依据概念关联规则，寻求蕴含关系，力求匹配准确和全面。

3.1.4 如果匹配记录为0的话，就需要相关档案专业人员结合国家档案局对电子文件保管期限的相关规定确定该元数据项目的保管期限，并参照表1及时将新增加的元数据添加到元数据库中。

3.1.5 在档案管理系统中设定归档电子文件到期自动检测功能，根据电子文件归档时间和保管期限，将到期的电子文件筛选出来以方便档案人员对其鉴定。

3.1.6 标题相同的两份文件，在添加和删除的时候，可以根据责任者、主题词、文件形成时间等其他元数据项目进行判断，以防重复添加或误删重要文件。

3.1.7 通过对抽取出来的元数据进行分析，发现大部分元数据的词性均为动词或名词，因此在抽取词汇的时候，首先应当过滤掉名词与动词以外的词汇，以减少计算的复杂度。此外，考虑到抽取出来的元数据还有一少部分是副词词性，主要有重大、重要和一般三种。鉴于此，笔者认为需要编一个例外词库，将这三个副词分别标明代码为1，2，3。对于某些三级、四级标识中的一般、重要以及二级标识中重复的词可以放到例外词库中，减少重复判断的次数。将一、二、三级标识中不重复的名词和动词放入元数据词库中。当判断一份电子文件的保管期限时，将抽取出来的关键词与元数据词库和例外词库中的词进行匹配即可。

3.1.8 对于事先有保管期限的电子文件，当自动鉴定完成后，要将自动鉴定结果和原有的保管期限进行匹配。如果匹配结果不一致，系统将文件的保管期限修正为自动鉴定保管期限。

3.1.9 规则说明：例如，表中15.2.10职工培训，一般的为短期保存，重要的为永久保存；15.5综合治理工作一般的为长期保存，重要的为永久保存。此外表中二级标识中多次出现通知、请示、批复、报告、总结、决议、决定等词语，可以将其放入例外词库中。

3.2 电子文件自动鉴定流程。将表征电子文件内容的元数据项目抽取出来，如：文件题名、主题词、责任者等项目。然后判断鉴定模块中的元数据库中是否存在该元数据，若存在，则进行匹配；若不存在，则人工判断该元数据是否需要添加到元数据库中。流程如图1所示：

3.3 电子文件自动鉴定实例。为了证明该方法的合理性和易操作性，笔者选取了部分电子文件，来验证该方法的可行性。笔者以建国后山西省×××局部分档案为例进行说明，如表2所示：

由表2可以看出第5份和第7份文件保管期限的鉴定结果与原有的不符，究其原因可能是鉴定人员缺乏相应的专业理论知识、各组织单位为了丰富馆藏、领导对档案鉴定工作不重视，等等。对于新产生的电子文件，可通过将元数据库嵌入档案管理系统中一次完成保管期限的鉴定。总的来说，该方法具有很强的适用性和准确性。

4 电子文件自动鉴定的实施

笔者认为电子文件鉴定需要经过三个步骤：事前鉴定、事中鉴定和事后鉴定。

4.1 事前鉴定。对原有的电子文件，首先由各职能部门档案人员对其进行初次鉴定；若是新产生的电子文件，直接转到第二步。

4.2 事中鉴定。当电子文件由部门传输到内部档案室时，需要档案室人员对其进行二次鉴定。对于原有的电子文件，为了避免人为判断造成的影响，要使用档案管理系统中的元数据库对其进行自动鉴定，来修正保管期限。对新产生的电子文件直接使用自动鉴定模块来确定保管期限。此外，档案人员应对电子文件自动鉴定过程进行记录和实时监控，以防设备出现异常。

4.3 事后鉴定。为了减轻档案管理系统的负荷量，当电子文件到期后，档案人员应该使用元数据库重新判断到期电子档案是否需要继续保管，如果需要，保管期限是什么。对于没有保存价值的到期档案，档案人员应该做好销毁记录，将需要销毁的电子档案导出到销毁清单中，经领导和各部门同意后方可进行销毁。

参考文献

[1]刘越南.关于档案价值鉴定的理论与实践（五） ——对电子文件鉴定问题的思考[J].档案学通讯，2001（5）.

[2]于慧敏.国外电子文件的鉴定理论分析及启示[J].兰台世界，2003（3）.

[3]谭琤培，章丹.档案元数据在电子文件鉴定中的运用——元数据研究之三[J].浙江档案，2002（6）.

[4]冯惠玲主编.电子文件管理教程[M].中国人民大学出版社.

核心元数据 篇6

关键词：移动核心网,安全性,网元冗灾

1 移动核心网冗灾必要性

随着移动交换技术的突飞猛进,核心网网元的处理能力飞速提高,导致核心网元的容量剧增,一般标准为十万、百万用户数量级,形成了典型的“大容量,少局所”,但这也带来了安全隐患:一旦核心设备发生故障,将引起大范围的通信故障。对通信系统可能产生巨大破坏的有自然灾害、社会灾害、人为灾害(误操作、病毒入侵等)和设备自身故障等。在一次次的惨痛教训面前,我们不得不思索移动交换网的安全问题,如何客观、合理评价现有交换核心网网元安全性,建立交换网元冗灾系统和体制是当前必须要考虑的问题。

2 移动核心网冗灾等级分析

冗灾对于通信网而言,是指需提供一个能防止用户业务遭受各种灾难影响破坏的通信网络。冗灾可以分为三个级别:设备级别、数据级别、网络级别。

设备级别冗灾是指在原有硬件及系统的设计中,为保证提供高质量的电信级服务,一般都已采用了双机热备份、集群技术、磁盘阵列等多种措施。在系统层面,采用重复覆盖、分层管理、高可靠集群软件管理等,可以最大限度地减少故障出现的概率、尽量缩小障碍造成的影响面。

数据级别冗灾是指灾难发生后确保用户原有数据的完整性、可靠性和安全性。数据级冗灾是目前使用比较成熟的一种冗灾系统,数据备份技术是数据级容灾系统中的核心技术。

网络级冗灾是建立在数据级冗灾的基础之上,它不但要求用户数据的完整性、可靠性和安全性,还要求系统的处理能力有冗灾的作用。网络级容灾系统能提供不间断或者极小间断的业务服务,让用户的业务服务请求能够透明地持续运行,感受不到灾难的影响,从而保证服务的完整、可靠、安全。网络级别冗灾是最高级别的冗灾,它要求整个通信网络有完整的冗灾机制。

3 移动核心网安全性问题分析

云南移动GSM网目前还处在2G时代,但经过了近几年网络建设后,2G移动通信核心网中引入了基于R4架构的移动交换网元,因此目前可称为R4GSM网,其核心网中主要包括MSS、MGW、MSC、TMSC、GMSC、STP、HLR、SCP、SGSN和GGSN等。目前核心网网络安全问题主要存在于以下方面:

从组网结构上看,R4 GSM核心网结构虽然与GSM相比有一定的变化,但是,其总体组网结构与GSM一样。由于GSM采取了树型的组网结构,因此单点故障不可避免对网络造成的影响,如:MSC失效,导致MSC覆盖区域的网络不可用;HLR失效导致HLR覆盖区域的网络不可用等。GSM组网没有针对网元失效的安全性措施,只是通过网元设备本身的可靠性措施,即设备的单板备份和端口备份来保证网元的安全。通常的解决方法是,尽量采取多个小容量网元的策略来规避风险,但这不能从根本上解决问题。另一方面,对于汇接的核心网元,如TMSC、STP、GMSC等,GSM在组网上采用了双平面的组网原则,这对于解决网元单点故障,保障网络安全起着非常重要的作用。

从单个网元的数据备份上看,目前核心网中各网元均有单独的数据备份机制,但备份周期和备份方式不尽相同。当前应根据不同网元的特点,工程进展情况和局数据变化频率等因素,合理制定各网元的数据备份机制。

从网元设备板级备份上看,由于云南移动GSM网中设备均采用了电信级的设备,因此核心网中的设备均已达到了设备级备份。但是,作为电信设备提供商提供的数据产品设备,绝大部分是集成传统数据设备厂家的设备,如华为公司的HLR设备,其数据库设备采用了IBM公司提供的小型机,这些设备是否也能提供电信级的服务?这应当是今后设备选型的一个注意点。

从网络管理上看,由于R4软交换技术的引入、大本地网设置以及网元集中化建设等带来了一系列的技术革新,这也对网络的管理提出了更高的要求,网络维护和管理水平能否跟上技术发展和网络革新也是制约核心网安全的因素之一。

4 云南移动核心网网元冗灾现状及目标分析

目前云南移动核心网网元的冗灾级别可分为两类,一类是达到数据级别冗灾,另一类网元达到了网络级别。第一类主要包括的网元有MGW、MSC、SCP、SGSN等,这类网元仅进行局数据和用户数据的备份,一般采用外挂备份介质,如磁带等,这类备份只能保证用户数据不丢失,不能保障网元瘫痪后业务的不间断。第二类包括的网元有MSS、TMSC、GMSC、STP、HLR和GGSN等。这类网元又分为三种情况,一种是HLR,从本质上看是一套大型数据库系统应用系统,它们存储着用户的基本数据。一种是MSS等网元,这些网元主要负责处理移动业务,同时也存储着用户的一部分动态数据,还有一种是TMSC、GMSC、STP、GGSN,这种网元主要侧重于业务处理。针对第一种和第二种网元目前网络上能实现完全的网络级备份,而对第三种网元,目前能实现部分甚至完全的网络级备份,受业务量和网元容量的制约。

对于核心网网元冗灾级别的需求,原则上建议,省级网元和覆盖整个本地网的网元应具备网络级冗灾,对于仅覆盖部分本地网业务或区域的网元建议采用数据级冗灾。当然,在技术条件和冗灾代价允许的情况,也可采用网络级冗灾。云南移动核心网网元冗灾情况及应具备的冗灾级别和当前技术支持程度如表1所示。

5 关于云南移动核心网网元冗灾的考虑

由于采用了电信级的设备,云南移动网上运行设备均具备了设备级冗灾,部分达到数据级甚至网络级。从保障通信网络的安全性和可靠性的角度出发,要求所有的网元都要具备网络级冗灾,但是从冗灾的技术实现和冗灾的代价上,又是不允许的,因此如何根据冗灾技术条件和冗灾代价,合理规划各网元的冗灾级别是当前应该考虑的问题,建议移动核心网网元冗灾应遵循以下策略:

(1)根据现有的技术条件对冗灾的支持程度,尽量考虑高级别的冗灾方案;

(2)在当前网络级冗灾无法实现的情况下,考虑一定的减灾措施;

(3)实时跟踪冗灾技术的发展,在冗灾代价许可的情况下,提高网元的冗灾级别。

以下针对现网网元逐个进行分析,提出当前条件下的冗灾考虑。

(1)MSC、SGSN:在2G网络下,网络基本上呈树型结构,采用TDM的传输方式,下级网元到上级网元是一一对应关系的连接,任何根部节点的故障将导致其下所有节点的失效,在这种结构下,网元的实时冗灾代价比较大,技术实现也有一定的难度。目前在云南移动现网中,MSC和SGSN主要采用的是灾难预防措施,即将网元管辖的业务的分散化,降低单个网元灾难带来的业务影响范围。但这仅仅是灾难的预防,能减灾但不能防灾,因此建议考虑有条件的情况下,可以考虑建设非实时的N+1冗灾,即容许一定的业务中断下的冗灾。如建设N+1灾备MSC或SGSN,通过TDM割接的方式实现冗灾,如图1所示。或者本地网中R4 MSC考虑一定的容量富余,用于对2G MSC灾备。

(2)MGW:MGW的情况如同MSC和SGSN,在2G的网络下,可参照MSC和SGSN的冗灾方式。在3G网络下,3GPP在R5版本提出了Iu-Flex技术,该技术使RNC不仅归属于某一个MSS,也使RNC可以连接多个MSS/SGSN网元,可被多个网元同时管理,RNC的终端用户可以按照负载均衡的原则注册到网元中的任意一个节点,从而实现MGW的冗灾。根据目前的技术条件,建议在有条件的情况下,可采用非实时N+1灾备MGW,在本地网增设1套MGW,作冗灾MGW使用,如图1所示。

(3)SCP:目前云南移动现网中设置了若干套SCP,SCP目前还只能做到数据级的冗灾。由于SCP的主要网络连接中仅涉及No.7信令网,网络结构相对简单,与HLR类似,因此建议,对SCP建设N+1灾备系统(可一并考虑VC的灾备),实现网络级备份。网络拓扑如图2所示。目前北京移动、浙江移动等都有应用案例。

(4)TMSC、STP和GMSC:根据GSM话路网及信令网组网原则,云南移动TMSC、STP均采用双平面的组网原则,其中TMSC还设置了TDM和IP承载的两张汇接网,即为双网双平面。双网按一定比例分摊话务,双平面网元负荷分担,保障网络的安全性。GMSC的设置也采用了成对设置原则,保障了网络的安全。对于这部分网元,建议关注双平面(成对)网元的网元容量设置,确保单个网元失效时,另一网元能在容量上满足业务要求即可。

(5)HLR:目前云南移动已建成了基于BOSS的HLR灾备系统,但存在以下问题:首先基于BOSS的灾备系统无法实现动态数据备份,导致接管过程中GSM重置,对No.7信令网冲击较大,接管时间长;其次,早期智能网用户不通过BOSS开户,这部分用户数据无法通过BOSS同步到灾备HLR等问题,建议重新考虑HLR灾备系统的建设,将现有灾备系统升级改造为N+X灾备系统,实现对NOKIA片区HLR的实时同步备份,同时,建设华为N+1实时灾备系统,实现对华为片区的HLR进行实时灾备。

(6)MSS:目前云南移动网上已针对两个主设备厂家分别设置了1套灾备MSS。华为灾备MSS通过“双归属”技术,已能实现对华为主用MSS的实时灾备,如图3所示;NOKIA灾备MSS通过IP承载网的倒换,也能实现非实时的灾备,如图4所示。在3G的网络中,采用“池组”(Pool)的技术来实现MSS的灾备,一个池组就是同类网元形成的一个公共服务区。但在目前的技术条件下,实现代价太大,因此建议暂不考虑针对MSS的其他方式的灾备。

6 结束语

核心元数据 篇7

近年来, 随着蛋白质组学技术的普及和基础研究的深入, 生物信息学正面临一系列新的挑战。对高度复杂的海量蛋白质组学实验数据进行存储、共享与整合即是其中最重要的问题之一。各个数据源在物理上的分布、结构上的互异以及语义上的差异成为了对实验数据进行共享与整合的三大瓶颈。

各个数据源的元数据不仅包含了数据的名称、类型等信息, 还提供了数据的上下文描述信息, 如果将各数据源的元数据按照一个统一的标准提取出来集中存放在一个元数据库中, 将集成的元数据信息与用户建立的用户模式的相应字段进行关联, 就能够通过解析用户模式得到对应的各数据源数据信息;将获得的各数据源查询结果进行连接、合并等操作, 并按用户模式进行输出, 就能够实现数据的共享和整合。根据以上分析, 课题组提出了基于元数据的蛋白质组学数据资源共享与整合方案, 并在此基础上已经实现了针对关系数据库中各异域异构的源数据库中的元数据信息集成到CWM的元仓库模型中。但是元仓库的管理员并不能控制源数据库 (以下的源数据库均为关系数据库) 中的元数据的变化, 如果源数据库的元数据信息发生了改变, 而元仓库不能进行及时更新同步的话, 就有可能造成元数据的悬挂, 对用户的查询结果产生不可估量的影响。如何捕获源数据库中的结构变化信息, 并将该元数据追加到元数据仓库中去, 成为解决问题的重点。

1 现有同步策略的分析与选择

目前关于数据同步策略的研究大多针对数据库中数据的变化, 而不是针对源数据库结构的变化, 但其思想可以借鉴。数据同步的基础是对象变化捕获, 它直接决定了数据同步的更新方式和选时方式。变化捕获不仅要获得复制对象的变化序列或当前映像, 还要在对等式复制时提供尽可能详细的控制信息。通过对当前使用捕获方法的综合分析, 目前主要有6种基本变化捕获形式, 它们是:基于快照法;基于触发器法;基于日志法;基于API法;影子表法;变更轨迹表法。由于基于快照发、影子表法和变更轨迹法的核心思想是变化后的数据库信息与原数据库信息进行比较, 最终得出变化的结果, 这种方法效率比较低下, 而且主流的数据库管理系统并没有提供关于数据库结构的快照信息, 因此这三种方式不太适合对数据库结构变化的捕捉;基于API法主要适用于小型的非关系型的数据库, 并且其是无法捕捉到的那些不经过API的操作;基于触发器法和基于日志法这两种方法运行的效率和通用性都比较高, 但基于日志法的实现方法相对而言更加复杂。在综合分析上述6种方法的基础上, 考虑到目前课题组主要考虑关系数据库的集成, 并且各主流的RDBMS如SQL Server, Oracle, MySQL, DB2等都提供了DDL (该触发器主要在响应数据定义语言语句时执行存储过程) 的触发器, 这里选择基于触发器法来捕获数据库结构的变化信息。这样可以利用DDL触发器来捕捉类似“用户建立新表”这类结构变化操作。

2 基于DDL触发器的元数据同步策略设计

经过以上分析, 最终设计了一个基于DDL触发器的元仓库与源数据库的元数据信息同步策略, 其基本思想如图1所示。该方法首先通过各关系数据库的DDL触发器捕获到其元数据的变化信息并保存到源数据库结构变化信息表中, 当元仓库的管理者向各数据源发送同步请求时, 将信息表中的信息经过SQL语句清理缓冲器整理后, 通过网络传送到管理元仓库的服务器中, 元仓库服务器最终经过词法分析器将源数据库的结构变化信息更新到元仓库中。

2.1 DDL触发器介绍

DDL触发器是一种特殊的触发器, 它在响应数据定义语言 (DDL) 语句时触发。它们可以用于在数据库中执行管理任务, 例如, 审核以及规范数据库操作。使用DDL触发器, 可以达到以下几种目的:第一, 要防止对数据库架构进行某些更改。 第二, 希望数据库中发生某种情况以响应数据库架构中的更改。 第三, 要记录数据库架构中的更改或事件。与标准的DML触发器一样, DDL触发器在响应事件时执行存储过程。 但与标准的DML触发器不同的是, 它们并不在响应对表或视图的UPDATE, INSERT或DELETE语句时执行存储过程。 它们主要在响应数据定义语言 (DDL) 语句执行存储过程。 这些语句包括 CREATE, ALTER, DROP, GRANT, DENY, REVOKE和UPDATE STATISTICS等语句, 然而这些语句正是引起源数据库的元数据信息改变的操作, 所以通过DDL触发器就能够方便地获得源数据库的结构变化信息。

2.2 源数据库变化捕捉器的设计

首先根据源数据库不同的DBMS编写相应的模块, 通过该模块调用DDL触发器, 将源数据库中的结构变化的信息保存到源数据库结构变化信息表中。以关系数据库中的SQLServer为例, 可以通过在其内部建立DDL触发器捕获捕获其的结构变化信息, 例如:特定数据库中某些表的信息变化, 表的删除、添加和表的属性字段的更新等, 都可以通过DDL触发器捕获到。在数据库中建立好一个DDL触发器后, 调用SQLServer系统自带的函数 ChangeCatch () , 就可以捕获有关激发 DDL 触发器的事件的信息, 并将其保存到ChangeInfor日志表中。但是ChangeCatch () 函数捕捉到的是xml 值, 而这里需要的是SQL脚本, 因此要采用以下的命令对其进行解析:

SET@cmd=LTRIM (RTRIM (REPLACE (@cmd, ″, ″) ) )

这样当对源数据库进行修改时, DDL触发器就会将修改的信息捕捉, 并保存到数据库的ChangeInfor的数据库结构变化信息表中。下面的数据, 是通过以上方法在SQLServer数据库中捕获到的结构变化信息的SQL脚本, 其结果如图2所示。

以上的示例展示了该方法在关系数据库SQLServer中的实现方法, 在其他的关系数据库中, 也可以效仿上面的方法, 实现数据库结构信息变化的捕获, 这里不再赘述。

2.3 SQL语句清理缓冲器的设计

由DDL触发器捕获的数据库的结构变化信息是将源数据库中所有的结构变化信息, 都以SQL语句的形式存储到相应的表格信息中。由于这些信息没有经过筛选和清理, 因此这些数据信息是杂乱无章的, 如果直接用这些数据信息对元仓库进行更新的话, 有可能会造成一些操作的冗余和无效的操作, 浪费元仓库服务器的资源。例如:在一个源数据库中, 由于某种需要, 对库中的某个表格A的结构进行了一些相应的改动后, DBA又将该表删除。那么无疑DDL触发器会将对表格A的改动操作和删除操作的SQL语句都进行了保存, 如果直接通过DDL触发器得到的信息与元仓库中的元数据进行同步一致的话, 那么原来对表A的修改操作, 使得在元仓库中相应的元数据也应进行修改。毋庸置疑这些操作基本上对元仓库的最终结构来说是无用的。因为最终该表在源数据库中被删除。以上这种情况在源数据库与元仓库的一致性过程中还有很多。为了避免这些无用的操作, 这里设计一个源数据库的SQL缓冲清理器。设计的基本原则是:首先将DDL触发器捕捉到的源数据库的变化信息保存到一张临时的信息表中, 当元仓库的管理者向源数据库提出获得变化信息的请求时, 先对这些信息进行清理, 拿上面表A的例子来说, 通过缓冲清理器的分析处理之后, 只需要最终把表A删除的信息传送到元仓库的服务器的相应模块中进行处理即可。这样不但解决了元仓库更新时无效操作等问题, 还减少了网络间数据的传送量。源数据库结构变化捕捉器的总体结构如图3所示。

2.4 元仓库更新的设计

当元仓库的管理者决定对元仓库进行更新时, 首先通过Internet获得源数据库的结构变化信息, 然后利用语法分析器对这些结构变化的SQL语句进行语法分析, 提取变化的元数据, 对元仓库进行相应修改。一般与关系数据库结构变化相关的SQL语句主要有表1所列情况。

SQL通常不提供修改模式定义、修改视图定义和修改索引定义等操作。用户如果想修改这些对象, 只能先将他们删除掉, 然后再进行重建。此外, SQL语言用Alter Table 语句修改基本表, 修改的内容一般有以下几种情况:

故此, 只需设计语法分析器, 分析上述SQL语句, 一种结构变化对应一个模块函数。提取函数是按照SQL脚本的BNF范式进行提取的。例如, 当语法分析器分析得到某条SQL语句中包含“Create Table”, 则自动调用CreateTable () , 将此新建的表及其所属的内容的元数据信息提取出来, 并把这些元数据信息转换成元仓库中对应类的对象。其他的操作方式也是通过类似的方法, 遇到Drop时调用删除模块进行提取, 遇到Alter时则需要根据其对表的不同的操作, 采取不同的应对措施。

当元数据提取完毕并通过完整性检查后, 元数据以对象的形式存在于缓存模块中, 根据元数据的更新情况将其分成两组, 一组为需要添加的元数据, 另一组为需要删除的元数据。由于修改操作被分成了删除和添加两部分, 为了避免添加过程的冗余, 先对元仓库中的元数据进行删除, 然后再进行添加。元仓库的更新流程如图4所示。

为了更好地支持数据信息的查询, 在元仓库中的元数据上建立了用户模式和语义元数据, 因此在元数据删除的过程中要对其进行判断是否建立了映射关系, 如果已经建立了映射关系的则提示映射关系的建立者该元数据已经不存在, 然后再将元数据删掉。

元数据之间存在若干依赖性 (或称相关性) , 它们制约着元数据提取与导入的先后顺序:被依赖的元数据必须先于依赖的元数据进行提取与导入。因此将要添加的元数据分成两类:基本元数据和相关元数据。因此导入的时候需要分成两步, 第一步首先向平台元数据库导入基本元数据, 即各种实体类的对象, 遍历每种实体类的实体对象 (实现时用链表管理) , 将其依次导入平台元数据库。第二阶段待所有基本元数据导入完成后, 便可以导入相关元数据, 即通过遍历每种关联类的关联对象 (实现时用关联对象中的引用属性管理) 依次导入平台元数据库。这种导入顺序确保了导入相关元数据时平台元数据库中已经存放了该数据可能用到的基本元数据, 有效解决了元数据相关性问题。经过以上过程, 最终达到了元仓库与源数据库的元数据的同步。

3 结 语

本文给出了在当源数据库的结构发生变化时, 如何对相应的元仓库中的元数据进行更新的方法, 并解决了因此种情况而引起的元数据悬挂的问题。课题组的最终目的是:通过本体标注元数据和用户模式的形式对各源数据信息进行智能化的查询。通过本体标注元数据后, 元仓库发生变化时, 智能地解决本体标注和用户模式悬挂的问题也在考虑解决中, 相关工作会在后续的文章中介绍。

数据仓库中多维元数据的组织研究 篇8

数据模型是对现实事物的反映和抽象, 它可以帮助我们更加清晰地了解客观世界。多维元数据是任何数据仓库应用的必要组成部分。它用来描述应用的许多方面, 包括等级之间的关系, 存储的公式, 数据在聚合前还是聚合后被存储, 经常改变的信息, 时间系列的信息, 项的描述和报表的注释, 安全性和访问控制, 数据更新状态, 格式信息, 数据来源, 预计算表的可用性, 以及数据存储的参数等[1]。缺乏这些信息, 实际的多维元数据将是不可理解的, 并且不能灵活地查看和更新。

近年来, 多维数据的相关技术引起了学术界的关注。目前为止, 国外学者们研究成果中比较有代表性的多维元数据组织模型考虑了如何表示多维元数据集合的维层次结构的问题, 提出的多维元数据组织模型只是部分的间接支持维层次结构的表示, 而不能直接地表示多维元数据集合的完整维层次结构[2]。国内对多维元数据组织的形式化等研究工作才刚刚起步, 陈微、李琪等人在这个领域进行了一些有益的探索。陈微等提出了一种对多维元数据和在多维数据库上进行的查询/统计模型化的方法, 给出了模型化的形式定义。着重讨论了多维元数据库维的划分问题, 以函数依赖为主要依据, 提出各维应满足正交限制条件, 并给出了维的划分算法。李琪、白英彩等提出了一种基于关系数据库的SQL的多维元数据组织概念模型, 该模型的层次链、层次树、维的定义支持不平衡、异构的维层次结构, 并在此基础上对SQL作了相应的扩充以支持多维的定义、多维层次比较、多维的引用和多维聚集层次的指定[3]。

本文就是主要研究数据仓库中的多维元数据, 提出了一种数据仓库的多维元数据组织模型, 提供了复杂多维层次结构表达机制, 能够很好地表达数据仓库的各种复杂层次数据结构和语义。

2. 数据仓库中多维元数据的设计

2.1 多维元数据的结构设计

多维元数据作为数据的数据, 可对数据仓库中的各种数据进行详细的描述, 说明每个数据的上文关系, 使每个数据具有符合现实的真实含义, 使最终用户了解这些数据之间的关系。数据仓库中多维元数据的主要工作是把所需的数据仓库工具集成在一起, 完成数据的抽取、转换和加载, OLAP分析和数据挖掘等[4]。如图1所示, 它的典型结构由操作环境层、数据仓库层和业务层等组成。

其中, 第一层 (操作环境层) 是指整个企业内有关业务的OLTP系统和一些外部数据源;第二层是通过把第一层的相关多维元数据抽取到一个中心区而组成的数据仓库层;第三层是为了完成对业务多维元数据的分析而由各种工具组成的业务层。图1中左边的部分是元数据管理, 它起到了承上启下的作用, 具体体现在多维元数据是进行数据集成所必需的;多维元数据定义的语义层可以帮助最终用户理解数据仓库中的数据;多维元数据是保证数据质量的关键;多维元数据可以支持需求。

在数据仓库环境中的多维元数据所扮演的角色和在操作型环境中数据所扮演的角色是不同的。在操作型环境中, 元数据几乎被当成文档来处理并且降低到同样的重要性级别。然而, 在数据仓库环境中, 多维元数据的重要性提高了。因为数据仓库多维元数据是给DSS分析者用的, 在DSS分析者计划该怎样去做信息型/分析型处理时, 他们要首先去看多维元数据。

2.2 多维元数据的维度建模

在数据仓库的整个设计过程中, 始终围绕的概念是元数据的维度。一般地, 元数据的维是关于一个组织想要纪录或透视的实体, 每一个维都有一个表与之相关联, 该表称为元数据的维表, 它进一步描述维。维度建模用于数据仓库数据库的设计中, 其目的是组织元数据以提高在分析和汇总大量元数据的查询效率。

元数据的维度建模针对零散的业务进程创建个别的模型。例如, 销售信息可以创建为一个模型, 库存可以创建为另一个模型, 而客户也可以创建为另一个模型。每个模型捕获事实数据表中的事实, 以及那些事实在链接到事实数据表元数据的维度表中的特性。元数据的维度建模将信息组织到结构中, 这些结构通常对应于分析者希望对数据仓库数据使用的查询方法。

元数据的维度表包含描述事实数据表中的事实记录的特性。元数据的维度表包含帮助汇总数据的特性的层次结构。例如, 包含产品信息的维度通常包含将产品分为食品、饮料、非消耗品等若干类的层次结构, 这些产品类中的每一类进一步多次细分, 直到各产品达到最低级别[5]。元数据的维度建模产生维度表, 在元数据的维度表中, 每个表都包含独立于其它维度的事实特性。例如, 客户维度表包含有关客户的数据, 产品维度表包含有关产品的信息, 而商店维度表包含有关商店的信息。查询使用元数据维度中的特性来指定对事实信息的查看。

3. 数据仓库中多维元数据的操作

与关系数据库不同, 数据仓库并没有严格的数学理论基础, 它更偏向于工程。由于数据仓库

的这种工程性, 因而可以根据它的工作过程分为:多维元数据的抽取、转换、存储和管理三个方面。建立好数据仓库之后, 还应该通过OLAP (联机分析处理) 建立起多维数据集, 然后通过一定的分析工具, 得出最后的分析结果, 整个设计如图2所示:

3.1 多维元数据的抽取

多维元数据的抽取是数据进入数据仓库的入口。由于数据仓库是一个独立的数据环境, 它需要通过抽取过程将数据从联机事务处理系统、外部数据源、脱机的数据存储介质中导入到数据仓库。多维元数据抽取在技术上主要涉及互连、复制、增量、转换、调度和监控等几个方面。数据仓库的数据并不要求与联机事务处理系统保持实时的同步, 因此多维元数据抽取可以定时进行, 但多个抽取操作执行的时间、相互的顺序、成败对数据仓库中信息的有效性则至关重要。

3.2 多维元数据的转换

针对多维元数据的转换操作, 本文以SQL Server为例进行研究。SQL Server数据库可以有6种多维元数据转换的方法:通过DTS设计器、利用Bcp工具、利用备份和恢复、直接拷贝数据文件、在应用程序中定制和通过SQL Server的复制功能。我们采用DTS设计器对多维元数据进行转换。

多维元数据转换服务 (DTS) 通过提供一组工具, 将来自完全不同的源的数据抽取、转换和合并到DTS连通性所支持的单个或多个目的, 以满足需求。通过使用SQL Server可以创建数据转换服务 (DTS) 包。具体步骤

分为:

(l) 选择源、选择目的;

(2) 在源和目的之间建立连接;

(3) 指定要移动的多维元数据以及希望使用的转换方法;

(4) 保存包、执行包。

在具体的应用中, 可以将需要的多维元数据从不同的数据库中提取并转移到指定的数据库, 以建立数据仓库。其具体是事实表和维度表的建立和转换。

3.3 多维元数据的存储和管理

数据仓库遇到的第一个问题是对大量多维元数据的存储和管理。这里所涉及的多维元数据量比传统事务处理大得多, 且随时间的推截而累积。从现有技术和产品来看, 只有关系数据库系统能够担当此任。关系数据库经过近30年的发展, 在数据存储和管理方面已经非常成熟, 非其他数据管理系统可比。目前不少关系数据库系统已支持多维元数据分割技术, 能够将一个大的数据库表分散在多个物理存储设备中, 进一步增强了系统管理大量多维元数据的扩展能力。

4. 结语

将数据仓库中的海量数据引入到多维元数据模型中, 并对其进行OLAP操作面临着巨大的技术挑战, 同时也是非常有意义的。目前, 面对数据膨胀和信息相对贫乏的局面, 多维元数据模型的引入使得从大量空间数据中获得信息变得更快捷, 同时也为进一步挖掘空间知识提供了坚实的基础。

参考文献

[1]王奕, 范通让.多级元数据查询系统体系架构的设计与优化[J].现代图书情报技术, 2007, (12) .

[2]L.Cabibbo, R.Torlone.Querying Multidimensional Databases.In:S.Cluet, R.Hull, eds.Database Proceeding Language, 6th International Workshop.Estes Park, Colorado, USA:Springer, 2007, 319-335.

[3]Coliat G.OLAP, Relational, and multidimensional database system.SIGMOD Record, 2006, 25 (3) :64-69.

[4]曾瑞, 陶跃华.数据仓库中多维数据模型的设计[J].云南师范大学学报 (自然科学版) , 2006, (06) .

元数据互操作透视 篇9

信息资源的内容、管理机制、实现信息资源共享的应用协议,涵盖了信息资源管理研究的主要内容。因此从这三个方面切入研究,是探索各部分涉及的元数据互操作问题、各异构数据系统间统一检索利用问题的有效途径。这三方面涉及的元数据互操作主要体现在三个层面:元数据格式层面上的互操作;元数据体系结构层面上的互操作;检索应用协议层面上的互操作。

1 元数据格式层面上的互操作

元数据格式层面上互操作的形式主要是元数据映射,即两种不同格式元数据之间的转换。转换可分两种形式:一对一的转换,通过源元数据的元素、语义、语法向目标元数据的元素、语义、语法的映射实现互操作,例如MARC向DC的转换;另一种形式有多种元数据参与,通过设定中心元数据格式,其他元数据格式通过向中心元数据的映射转换,最终实现多种元数据间的互操作,例如OAI就选用DC做为中心元数据格式,各异构元数据系统都向DC映射转换实现互操作。

元数据转换涉及单向转换和双向转换。单向转换只允许从源元数据向目标元数据的映射,不允许此过程逆向。双向转换允许逆向转换。各种元数据结构和语义上的不同,造成了元数据在映射过程会出现不同差异,主要分为结构映射差异和语义/描述规则映射差异。

结构映射差异可分为以下2种情况:1)一对多关系,即源元数据的一个元素与目标元数据的多个元素相对应,从而在映射时造成差异,如DC的subject元素与MARC中的多个6XX字段对应这种情况。在双向转换中,又表现出多对一的关系;2)无对应关系,即源元数据的一个或多个元素在目标元数据中找不到对应的元素造成的映射差异,如DC中date的modified元素在MARC21中就没有对应的元素等。

语义/描述规则差异主要有以下4种情况:1)某些元素在源元数据中是可选元素,在目标元数据中是必备元素带来的差异。如源元数据中的可选元素缺省,目标元数据无法赋值,从而导致映射操作出错;2)可重复元素带来的差异,如源元数据中是可重复元素,目标元数据中为不可重复元素,从而带来元素无法取值,导致映射出错;3)有无子元素带来的差异,即如何解析源元数据元素的子元素向没有子元素的目标元数据元素的映射问题;4)元素层次错位问题,一般来说这是因为元素的语义差异造成的,会涉及语义的解析规则问题。

为了降低这些问题导致的元数据转换过程中的信息丢失,通过对元数据的“附注”、“提示”等保留字段的操作,及在转换过程中加入补充数据、规范转换过程的解析规则等措施,可在一定程度上解决映射差异带来的影响。

2 元数据体系结构层面上的互操作

从对元数据互操作的理解上来说,我们可以把元数据的元素映射看作是微观层面的工作,对体系结构层面的互操作可考虑为宏观层面上的问题。XML由于描述能力、高度结构化、扩展能力等方面的优势,为许多元数据互操作模式提供了基础语法支持。很多元数据互操作方案都基于XML。XML-DTD模式、XML Schema模式、RDF模式是三个典型实例。

2.1 XML-DTD 模式

DTD是XML标准的文档类型定义方式,每种格式的元数据都可以由XML-DTD定义。只要能够解读XML语言的系统都可以对被DTD统一定义的元数据格式予以辨识,从而解决异构元数据格式的解析。DTD包含定义元素的元素声明和属性列表,元素声明中的元素组成了词汇表,元素的属性列表指出了元素的属性。也就是说,可以通过对各元数据格式的统一定义,形成一个元数据的重用机制,扩展元数据格式适用范围,兼容不同元数据,促进元数据间的互操作。DTD在简单的文档结构定义方面是较为出色的,但由于DTD本身的局限性,实践中问题较多。DTD仅支持自己的特殊语法,使编写DTD和XML文档需要两套不同的规则。DTD只支持字符型数据,不支持Name Space,扩展性不强,不具开放性,以及DTD格式书写、理解困难,不易用程序进行自动化处理等都是其不足。

2.2 XML Schema 模式

与XML-DTD相比,XML Schema本身即是规范的XML文档。它利用XML的基本语法规则来定义XML文档的结构,实现了由内向外的统一,易于编辑,且能用XML工具解析。这是区别于DTD的一个本质变化。XML Schema有良好的扩展性,在简单数据类型基础上允许用户扩展数据类型;主持属性分组,属性的应用范围多样,可以针对不同元素进行;支持Name Space,能在同一文档中加载多个schema定义;具互换性、规范性,可利用高层次的数据转换约束XML文档中标识的使用。显然,XML Schema可看作是DTD的延伸,包含了DTD能实现的所有功能。Schema也有其不足,例如可读性不如DTD,需要高版本浏览器支持等。许多研究表明,在DTD和Schema的转换中,推荐由前者向后者的转换,以实现“完全转换”,以便充分利用Schema的优点。

2.3 RDF 模式

RDF是W3C提出的用于描述WEB资源的标准,现已成为Semantic Web研究的核心概念之一。用RDF描述元数据格式,意味着只要能够解析这个标准描述框架,就能够解读相应的元数据格式,进而实现互操作。具体实践中,RDF是间接利用了元数据复用机制,通过把所有格式的元数据集中到一起,交换对WEB资源服务的描述,实现多种元数据在异构系统间的共享。实际上,RDF并不直接定义具体元数据,而是通过一个“资源——属性——值”的三元组来提供元数据的基本使用模式,并通过XML Name Space机制引用已有的元数据格式中的元素定义,从而直接使用合适的元数据元素做为三元组中的属性来描述相应资源。这也是RDF被认为是间接利用了元数据复用机制的原因,它并没有真正直接定义具体元数据。DTD和Schema都对具体元数据进行了定义。对各资源描述团体(如DC)来说,RDF也并不为他们规定语义,而是为其提供了据需要定义元数据单元的能力,这也是它的高明之处。作为一种WEB资源描述通用框架,RDF以计算机容易理解的方式表示,可以很方便的进行数据交换,提供了WEB数据集成的元数据互操作方案。

此外,RDF用XML表达只是方式之一,通常表述为RDF/XML。还有另外两种方式,即Notation 3和图形。因为计算机目前无法理解RDF的图形表示,Notation3相比RDF/XML虽然更为简洁,但时下对它们的研究还不是太成熟,在元数据互操作方面的意义有待进一步研究。

3 应用协议层面上的互操作

在应用协议层面上,元数据互操作可通过定义一个公认的、相互支持的协议实现。OAI和Z39.50就是两个这样协议。

3.1 基于 OAI-PMH 的互操作

Open Archive Initiative,是一个应用于交互平台上的检索、发布数字化信息资源的协议,最早源于电子出版界的互操作计划。其简单,灵活,平台独立,在许多领域都有应用。OAI制定有元数据采集标准OAI-PMH,其利用元数据开放搜寻机制来实现元数据的互操作。

OAI-PMH采取元数据收割模式,提供了独立于应用的互操作框架。基于OAI-PMH的元数据互操作框架主要包含三个组成部分:数据提供者(DP),服务提供者(SP),元数据搜寻协议。OAI协议是数据提供者和服务提供者之间的通信应用协议,架构于HTTP协议之上,提供六个核心的操作指令。服务提供者通过这六个指令向数据提供者获取元数据资源,并向用户提供增值的检索服务。

OAI定义了两个主要参与者:数据提供者、服务提供者。当服务提供者定期或定量的通过OAI协议向数据提供者发送收集元数据的“请求”,以向用户提供统一资源检索服务时,数据提供者需要将其元数据格式统一转换为所要求的DC格式,并经过XML编码,反馈给服务提供者。之后,服务提供者将收集到的元数据存储到本地数据库,然后通过统一的检索界面为用户提供服务。过程中,DC起到了中介元数据的作用,各种格式的元数据通过到DC的映射转换实现互操作。严格来讲,OAI-PMH只是一个元数据采集标准,只采集元数据,不采集信息内容。任何一个数据提供者都可以向多个服务提供者提供元数据,一个服务提供者也可以向多个数据提供者获取元数据;对于一个组织来说,它即可以是数据提供者也是可以是服务提供者。

3.2 基于 Z39.50 的互操作

Z39.50是“开放系统互联参考模型”(OSI-RM)的应用层协议,涉及面向连接的、程序间的通信问题,它使得用户在一台客户机上检索存储在另一台计算机(服务器)上的信息,而不必关心这些信息的存储和组织结构。被图书情报界广泛的作为一种访问分布式数据库的方法使用,成为检索远程图书馆书目信息的国际标准。

Z39.50在互操作问题上呈现为一种检索转换机制。它将异构系统的检索指令和结果按照一种公共方式表达,从而支持异构系统间的检索,保证互操作实现。在检索中,检索者使用本地机系统及自己熟悉的菜单和命令输入查询提问,驻于本地系统中的Z39.50源模块将提问请求翻译,转换成由Z39.50定义的标准格式,并发送给有着Z39.50目标模块的数据库系统,目标模块将转换过的检索提问和命令提交给数据库进行检索,并将检索结果以标准格式返回给源系统,而源系统又以其格式和方式将结果输出给用户。从而实现用户用其所熟悉的指令、格式来检索任意异构系统数据的目的。一个检索系统可同时装入Z39.50的源模块和目标模块,既可作为客户机向其他系统提出请求,又可作为服务器回应其他系统的请求。

元数据注册开放论坛即将召开 篇10

由ISO/IEC JTC1/SC32主办,国家标准化管理委员会承办的JTC1 2010年会将于2010年5月19～28日在我国昆明市召开。会上,将召开ISO/IEC JTC1/SC32(数据管理与交换)全会、SC32/WG1(电子业务)、SC32/WG2(元数据)、SC32/WG3(数据库语言)、SC32/WG4(SQL/多媒体和应用包)等SC32全会和工作会议。

在SC32全会之前,中国电子技术标准化研究所将于5月1 7～1 8日承办第十三届元数据注册开放论坛(OFMR2010),论坛主题是“元数据和云计算”。目前已有来自于美、英、法、德、加拿大、澳大利亚等国家的1 00余名专家和代表注册参加开放论坛。