数字图书馆系统设计(二)
文件类型：PDF/Adobe Acrobat 文件大小：字节
更多搜索：数字 图书馆 系统 设计
数字图书馆系统设计(二)
——信息资源的结构与设计
主讲田捷博士
(研究员,博士生导师)
Email: tian@dr.com
http://www.digiark.com/tian
一,概述
二,元数据基础
三,Dublin Core标准的发展
四,XML的应用与发展
五,资源描述框架(RDF)
六,数字图书馆结构的设计
一,概述
数字图书馆系统是现代计算机及网络技术
与传统图书馆信息检索技术相融合的结晶.传
统图书馆管理面临着技术与设备的落后的局面
,但是长期针对海量数据的管理积累了丰富的
信息检索经验;现代网络计算经过互连网时代
的飞速发展,在信息的数字化技术,多媒体技
术,信息的存储与安全,网络发布与搜索技术
等方面日趋成熟,但是面临海量信息的管理暴
露出诸多问题,如何将两者有机地结合,是数
字图书馆系统设计的关键.
图书馆针对海量信息的管理采用的元数据
概念被借鉴到计算机领域,成为数字图书馆系
统中对信息进行组织和管理的基本方式,同时
通过互连网技术中的XML语言,按照W3C制定
的资源描述框架RFD,可以实现对海量资源的
同一分布式管理.
随着WWW的不断发展,网络上信息资
源正呈不断增多的趋势.但随之而来的问题
是,人们发现在海量的信息环境中,信息的
查找和检索变得越来越困难.网络上充斥着
各种各样的信息,但人们却不知道究竟该怎
样才能找到自己所需要的信息.
二,元数据基础
为了有效地解决查找网络资源这一问题,元数
从元数据提供者的角度来看,元数据能改
进文件的检索能力(特别是搜索的精确性),
以及对藏品的控制和管理问题.而各种网络上
的搜索引擎,如Lycos,Alta Vista,Open Text
等,虽然对许多资源有自动索引功能,但其查
准率却极低.而一些由专业人员提供的不仅复
杂并被结构化的特殊体系方案,如MARC,
GILS,TEI header,IAFA模块(用来描述匿名
的FTP档案和基于主题的信息网关)和FGDC,
这些标准虽然能达到一定的查准率,但在数据
加工标引工作上既费时又费人工,并且需要的
是专业的从业人员,因此对于充斥于网上的海
量信息可以说是无能为力.这些复杂的体系方
案通常都需要大量的时间,金钱和合格的职员,
因此创造一个更简单的元数据模型和体系方案
显得非常吸引人.而且,随着因特网上的搜索
服务的改进,从各种复杂或简单的元数据格式
到各个不同的用户团体之间,也特别需要一种
标准化的语言或交换格式.
所以,创立一个简单的,并且在网络中为各个
1995年3月在都柏林召开的第
——都柏林核心元
(Dublin Core Element Set),简称为都柏林核心
DC).由于它的简练,易于理解,可扩展,及
DC进
DC在结构和功能上逐
DC能较好地解决网络资源的发现,控制和管理
DC的各种项目已遍及美洲,欧洲
DC已被翻译成了二十多种语
1998年9月,因特网工程专题组(IETF)也正
DC这一网络资源的描述方式,将其作为
RFC2413).
三,Dublin Core标准的发展
DC-1 1995年3月1-3日,第一届元数据研讨会在
美国俄亥俄州的Dublin召开.会议由联机图书
馆中心(OCLC)和美国超级计算应用中心(
NCSA)主持.与会代表包括来自图书馆界,
档案界,人文学界和地理学界,以及来自Z39
.50和通用标记语言标准(SGML)集团的代
表.大会的目的旨在确定所研究的问题的范围
,即是否只要一个简单的元数据元素集就能对
网上的各种主题资源进行描述,会议为进一步
发展描述电子资源的元数据元素的定义打下基
础.
由于资源描述的广泛性以及复杂性使商讨
的范围受到了限制.现在网络上的绝大部分信
息对象都被看作是"文件",而元数据记录是用
来直接帮助发现因特网上的资源的,因此提出
的一套元数据元素集旨在描述支持电子文件资
源的发现的基本特性.而其它涉及成本核算或
档案的信息,都不在商谈之内.
在这次会议中,专题组的目的主要是为了培
养对当前问题的一般性的认识,以及主要涉及者
可能会采取的解决方法,并提出一个核心元数据
元素集来描述网络上的电子资源.会议目标主要
是为了定义一个能被全球所理解接受的小的元数
据元素集,它能允许作者和信息提供者自己来描
述自己的工作,并能方便资源发现工具之间的互
操作性.但是核心元素并不能满足特殊用户团体
需要的对象描述.
这届研讨会最主要的成果是设定了一
个包含十三个元素的都柏林核心元素集:
Dublin Core(或简称为都柏林核心DC)
.都柏林核心是在网络环境如因特网中,
帮助发现文件类对象所需要的的最小元数
据元素集.而它的结构句法问题则作为一
个执行细节没有进行详细说明.[DC-1]
DC-1所定义的十三个元素如下,在后文
中可以看到,这十三个元素在以后的DC发展
中从名称到内容都有了很大的变化:(关于
DC的详细定义请参见原文或相关文献)
Subject:主题
Title:题名
Author:作者
Publisher:出版者
OtherAgent:相关责任者
Date:出版日期
ObjectType:对象类型
Form:格式
Identifier:标识
Relation:关联
Source:来源
Language:语种
Coverage:覆盖范围
英国的UKOLN(The UK Office for Library
and Information Networking)的DESIRE
(Development of a European Service for
Information on Research and Education)项目专
门对现有的多种元数据类型进行了分析和比
较,并把它们分为了三个级别:
一级二级三级
记录简单格式结构化格
式
复杂格式
特征私有成为逐渐形
成的标准
已成为国
际标准
全文索引结构化字
段
详细标识
记录格式LycosDublin
Core
ICPSR
AltavistaIAFA
templates
CIMI
Yahoo etcRFC 1807EAD
SOIFTEI
LDIFMARC
级别一包括的是相对来说未经结构化的
元数据,特别是从资源中自动抽取并索引的.
这些数据一般是由搜索引擎产生的.如果用
户用它们来查询一个已知条目,它们还比较
有用.但用户必须对查出的大量资源进行筛
选,并且还可能会错过一些潜在相关的资源,
因为它们没有使用适当的术语进行索引.
级别二中包括的元数据允许使用者不用
对资源进行检索或联系,就能对资源的潜在
用途或重要性进行判断.这些数据已被结构化
并支持字段查询.更重要的是这些简单的数据
记录能让非专业用户自己来创造,而不需要什
么特定学科的知识.描述一般是手工进行的,
或是用自动抽取的描述来帮助手工编制.
级别三中复杂的描述格式能用于定位
(location)和发现,还可用于对对象的证明
(document)和收藏(collection),它们一
般用于研究与学术活动,需要专业知识来创
造和维护,并迎合专家们在特定领域的要求.
在这样的一个背景中,可以发现在各个级别
间有一种跨越的趋势.由作者或站点制作的
元数据在很多方面将会变得越来越重要.
[DESIRE]
在上面这个图表中我们可以看DC被置
于第二级别中,它所提供的记录是为了调
和级别一和级别三这两种极端,来提供一
种简单结构的记录.DC并不是要替代其它
的资源描述类型,而是对它们进行补充.
DC能通过扩展或通过对更复杂的记录的链
接来增强其功能,并被对应到其它更复杂
的记录中去.
DC-1会议集中讨论了文件类对象(DLO)
的信息检索所需要的元数据元素.因为DLO至
今仍是因特网上的资源主流,并且适用于DLO
的任何处理方法都能被扩展到其它类型的资源.
由于因特网上所包含的信息要比以往的专业摘
要人员,索引人员和编目者所用的方法及系统
管理的信息多得多,因此一个可行的获得电子
资源的元数据的方法是:让作者和信息提供者
无须经过对现有标准的特别培训,就能自己来
描述资源.
美国会图书馆的Rebecca Guenther指出DC具
1)DC将鼓励作者和出版者以自
2)它将鼓励包含有元数据元素模块的网络出
3)如果有可能的话DC生成的记录能
4)如果DC成
DC具备如下一些特性:内在性
(intrinsicality),可扩展性(extensibility),
独立句法结构(syntax independence),可选择
性(optionality),可重复性(repeatability)及可
修改性(modifiability).
元数据专题组的讨论透露了指导元素集
进一步发展的原则.伴随着这些原则将出现
这些可能:核心元素集越小越好,且能被大
多数用户所理解,元素集能灵活的描述广泛
的主题区域内的资源.[DC-1]
2,DC-2
第二届元数据研讨会是由UKOLN和OCLC
组织的,它于1996年4月1-3日在英国的
Warwick召开.它旨在扩大第一届OCLC/NCSA
元数据研讨会的影响.第一届会议主要围绕一
个简单的资源描述记录的产生展开了讨论,即
广为人知的都柏林核心元素集DC,并最终达
成了共识.它可作为一个统一各种网络资源描
述模型的基础.
在Warwick召开的会议上,出席的
人员有计算机专家,文本标示人员和
图书馆专家.还有美国数字图书馆倡
议项目的代表,英国JISC电子图书馆
项目,以及欧洲和澳大利亚图书馆方
面的代表.另外还有如ARC这样的标
准制定团体及一些公司的代表.
第二届研讨会的目的主要是"确认能满足两个目
的的执行策略:
促进各学科和语言间的语意协作能力;
定义一种可扩展的机制来支持对其它描述模型的更
详细的描述和联接."
但研讨会的重点很快就转移到了可扩展性问题上,
其它问题基本未被触及.
主题组还讨论了句法(syntax),国际化
(internationalisation),特殊符号集(character
sets in particular),对象描述与它们的集合
间的间隔(the granularity level of object
descriptions and their aggregation),及必要
的用户指导(necessary user guidelines)与促进
工作(promotion work)等问题.
研讨会最主要的成果是提议了一个元数据
的容器结构(Container),它可以包含DC以及
其它一些不同类型的元数据.DC的十三个元素
则没有改变.
这次会议产生的元数据结构的概念基础,
被称为Warwick框架.这个框架和Meta
Content[MCF]框架,成为了资源描述框架RDF
(Resource Description Framework)发展的核心
.[DC-5]
Warwick框架具有两个方面的重要性.首先,
它提供了一个广阔的定义和使用各类元数据的
结构框架.其次,把Warwick框架作为一个环
境,它能允许有特定目的的元数据集开发者对
自己的工作进行限制和集中,使其它对元数据
感兴趣的团体能独立的在满足自己
特定需要上取得进展.[CLIIFFORD]
RDF[RDF]是在W3C的主持下开发的,它
是对结构化的元数据进行编码,交换和再运用
的一个基础结构.RDF能允许在一定的语义,
句法和结构中进行元数据之间的交互性操作.
RDF为基于网络的元数据,包括超出在资源内
嵌人描述性的元数据的各种元数据联合模型提
供了一个灵活的句法结构基础.
随着内含元数据越来越受重视,DC和
Warwick框架需要在浏览器和搜索服务提供者
间得到提倡.1996年由W3C赞助的"分布式索
引和搜寻研讨会",其中一个议题就是"从计划
资源收集和出版元数据的标准.例如,是否
应将DC元数据说明加入HTML来改进HTML
文件的可搜索性.
[DC-2]
DC-3 1996年9月24-25日,由网络信息联盟(
CNI)和OCLC在美国的俄亥俄州的Dublin 组
织了第三届元数据研讨会.会议专门围绕在
网络环境中描述图象和图象数据库的问题进
行了讨论.参加的专家包括来自计算机学,
图书馆学,联机信息服务,地理信息系统,
博物馆和档案馆的控制,医学图象和其它领
域的专家来探讨网络图象资源的描述问题.
其目的在于促进描述,发现和组织网络图象
和图象数据库资源的标准和协议的发展.
现在在因特网上的数字图象,包括从图画
和建筑图到CAT扫描图,从X光片到星球地表
图和天文对象图.本次研讨会主要集中讨论
了静止的图象,如图片,幻灯片和图解.而
动态的图象,如电影,录像之类都不在考虑
之列;另外也不包括文本对象的图象,如传
真页面等.DC将确定符合所有学科的对图象
和图象基地的普遍需要,如艺术,建筑,机
械工程,医学,生命及社会学.
第三次的研讨会达成了一种共识,认为DC
在Warwick框架中,可做为一个在网络环境中
用于图象发现的简单的资源描述模型基础.
[CNI/OCLC]
图象到底有什么不同之处
在第一届的元数据研讨会上定义的DC最初是
用来描述DLO的.现在为了描述网络上的数字
图象,有必要把DC做一些修改,以使它能适
应图象描述的要求.那么,图象与DLO到底有
什么不同呢
首先,图象的编码策略要严格得多.因
为文本文件的表现形式要更少一些.其次,
文本材料能被索引,这通常能简化或使描述
的工作部分自动化,而图象的大部分描述元
素则是在这些工作之外的.最后,检索图象
对于时间与带宽的要求通常都是很高的.
随着因特网上复杂图象的运用越来越
多,元数据将在图象的发现和选择方
面发挥越来越重要的作用.表示这些
图象所必须的信息包括:
种类(位图,矢量,视频)
格式(TIFF,GIF,JFIF,PICT,PCD
,EPS,CGM,TGA等)
压缩策略和比例(JPEG,LZW,
QuickTime)
维数
动态范围
色彩查找图表和相关尺度(metrics)(
CMYK,RGB等)
充分捕捉这些信息,并对它们进行编码与
DC最初的设计目的:简约形成了冲突.如果
DC被用于图象领域中,它就必须确定一个可
扩展的机制,来支持如前所述的图片所需的更
丰富的描述符的编码.
DC元素的修订
在第三次元数据会议中对DC的
几个元素进行了修改,以使它们
不至于太以文本为中心.
另外还在原来十三个元素的
基础上又新增加了两个元素:
Description和Rights.
描述(Description)
Description与Subject现在成为了两个独立
的元素,因为图象专家认为它们对于图象来
说是两个截然不同的概念.
这样,Subject将包括关键字,控制词条
和正式分类指定标准.而Description则用于图
象方面的描述性文字或内容描述,并包括文
本文件下的摘要.
权限管理字段(Rights Management)
权限管理字段被认为是一个核心描述
记录的必要组成部分.它对于图象描述极
其重要,因此如果不包括这一元素将阻碍
DC在图象领域的广泛应用.
有关DC十五个元素的中文定义简介如
下:
元素描述:
1.题名Title
标签:"Title"
由资源创建者或出版者给定的资源名称
2.作者或创建者Author or Creator
标签:"Creator"
对创造资源知识内容付主要责任的个人
或机构.
例如:书写文献的作者,视觉作品的艺
术家,摄影师,或插图画家等.
3.主题及关键词Subject and Keywords
标签:"Subject"
资源的主题.通常是描述资源主题或内容
的关键词或词组短语.建议采用受控词表和规
范的分类体系.
4.描述Description
标签:"Description"
资源内容的文本描述,包括文献类对象的
文摘或视觉作品的内容描述等.
5.出版者Publisher
标签"Publisher"
负责使资源成为当前形态的责任者,例
如出版社,大学的系科,或者公司实体等.
6.其它责任者Other Contributors
标签"CONTRIBUTORS"
指并没在Creator元素中列出的对资源的
知识内容具有重要贡献的个人或组织,其贡
献次于创建者(如编辑,誊写员,插图作者
).
7.日期Date
标签"Date"
指与创建或使资源成为可利用状态相关
的日期.注意与Coverage元素中代表资源作
为知识内容所覆盖的时间属性相区别.推荐
最好采用ISO8601(参见W3C技术规范http:
//www.w3.org/TR/NOTE-datetime"日期及时间
格式")所规定的YYYY和YYYY-MM-DD表
达方式,例如日期1994-11-05 即表示1994年
11月5日.
8.类型Resource Type
标签"Type"
资源的类别,例如主页,小说,诗歌,手
稿,技术报告,论文,词典等.资源类型通
常由类型列表中选取.为了提高互操作性,资
源类型值应从资源类型列表中选取,目前这一
列表正在发展完善中.
9.格式Format
标签"Format"
资源的数据格式,用于注明需要什么软件
或硬件来显示和执行这一资源.为了提高互操
作性,格式值应从格式列表中选取,目前这一
列表正在发展完善中.
10.标识Resource Identifier
标签"Identifier"
用来唯一标识资源的字串或数字.例如网
络资源标识中的URL和URN(经过解释后),
其它通用唯一性标识如国际标准书号ISBN或
其它规范名称皆可作为标识值.
11.来源Source
标签"Source"
二次资源的出处信息.一般的元素只包
含当前资源的信息,如果对于揭示当前资源
是必要的话,该元素可包含二次资源的日期
,创建者,形式,标识,或其它元数据.推
荐最好使用关联Relation元素.例如,可以用
来源元素的date of 1603描述方法表示1996年
改编电影来源于莎士比亚戏剧原作,但最好
采用关联元素的改编自"IsBasedOn"参见至另
一个资源,而在这一被参见的资源描述中包
括date of 1603的描述.如果当前资源为其原
始形式,来源元素不可用.
12.语种Language
标签"Language"
资源知识内容的语种.如有可能,该字段
内容应遵从RFC1766的规定[语种描述的标记规
范http://ds.internic.net/rfc/rfc1766.txt ];例
如en, de,es,fi,fr,ja,th, andzh(ISO 639)等
13.关联Relation
标签"Relation"
二次资源及其与当前资源关系的标识.该
元素允许在相关资源和资源描述间建立关联.
例如再编自(IsVersionOf),翻译自(IsBasedOn)
,节选自(IsPartOf),格式转换自(IsFormatOf)
等.为了保证互操作性,关联值应从关联列表
中选取,目前这一列表正在发展完善中.
14.覆盖范围Coverage
标签"Coverage"
资源知识内容的时空特征.空间范围指
物理区域,如天穹;坐标,如经度纬度;来
自于规范词表的地名或全称.时间范围指资
源内容,而非资源产生的时间(由日期Date
元素表示).时间描述(通常是一个时间范
围)采用与日期Date相同的格式(基于
ISO8601的W3C技术规范http:
//www.w3.org/TR/NOTE-datetime"日期及时
间格式"),或者采用规范列表中的时间范
围描述或全称.
15.权限管理Rights Management
标签"Rights"
一个权限管理的陈述,或者是指向一个
权限管理陈述的标识,或者是指向提供资源
权限管理信息内容的服务器的标识.
把DC与其他元素集进行桥接
第一届元数据会议的一个切实成果就是由
美国国会图书馆的Rebecca Guenther提出的把
DC元素和MARC字段进行桥接.这一研究报
告使大家意识到DC可作为网络资源描述的一
个模型,并且对于MARC的加工处理变动有一
定的反作用.
类似的DC元素与现有的图象描述标准之
间的桥接,使DC在图象处理中起了导向作用
.正如专题组的研究列表中所建议的,现有的
标准和实践可作为指导方针开发的模式,并因
此减少开发描述标准所须的工作.[DC-3]
DC-4 1997年3月3-5日,第四届元数据会议在澳
大利亚首都坎帕拉召开.本次会议的主持者是
OCLC (The Online Computer Library Center),
DSTC (the Distributed Systems Technology
Centre),和NLA (the National Library of
Australia).
本次会议最直接的结果就是产生了两大学
派:最小主义学派和结构语言学派.
最小主义学派指出DC的最主要特征是它
的简约性.这种简约性对创造元数据(如由
对编目技术不很熟悉的作者)和利用工具(
如对细节的限定词或编码策略起的作用不大
的索引引擎)来使用元数据是非常重要的.
只有当一个简单的核心元素在各种情况下所
蕴涵的意义都相同,才能达到在各团体间的
语义互操作性这一目的.附加的限定词能指
定,修正并详细说明元素的含义.由于这些
将在不同的时间由不同的集团以不同的方式
来完成,因此在元素的语义方面也许会出现
变化,这在一定程度上会影响语义互操作性
.
结构语言学派也意识到了在更灵活的正式
的扩展和限定元素交换方面会出现元素语义变
化的危险.但却认为最重要的是元数据内容的
限定能力.
DC-4正式确定了附加的DC限定词(坎帕
拉限定词),它们是模式体系(SCHEME),
语言描述(LANG)和属性类型(TYPE).
语种描述(LANG)
这一限定词指定了元素值的描述字段的
语言,而不是资源本身的语言.由于网络上
的多种语种问题越来越突出,这个限定词也
变得越来越重要.迄今为止,英语被假定为
是网络上的语言,但这一现象正在改变,确
定资源本身和资源描述的语言问题变得极为
重要.
模式体系(SCHEME)
SCHEME限定词用来确定给定元素的遵从
的已有的或正在讨论中的一个体系结构中的合
法值,如分类表,专题词或各类代码表.如一
个SUBJECT字段可以是一个体系限定为LCSH
(Library of Congress Subject Heading )的数
据.SCHEME限定词对应用软件或应用人能提
供一个处理线索,以使被限定元素能更好的使
用.然而在其它情况下SCHEME标示符对字段
的使用,日期的翻译都非常重要.
TYPE (Sub-element Name)属性类型(子元素
名)
这个限定词指定了给定字段的一个方面
.它的用途是缩小字段的语义范围.它同样
可被看作是一个子元素名,TYPE限定词改正
的是元素的名称,而不是元素字段的内容.
TYPE是DC限定词中争论最大的词.在明确
定义可接受的类型以及怎样定义上有一些逻
辑困难.在某种意义上,它不是一个限定词
,而是元素名本身的一个子集.[LIB]把元数
据结构与特许命名域代理联系起来限定词可
以是受控制的命名域的一部分,命名域可以
是任意指定的.在联机环境中,可以通过超
链来完成.例如:DC.TITLE是DC元数据
元素集中的一个元素名,在这里DC就是一个
特许命名域,并有一些团体负责对这一命名
域中的内容进行解释.如LCSH是一个体系
(SCHEME)的名字,它也是一个命名域,
它的权限代理单位是国会图书馆.
对于权限代理机构不一定要有机器可代理的
链接.例如,SCHEME的LCSH标示符即使是在
没有这种链接的情况下也非常有用,因为这个
标示符具有一定的可信度并被公众普遍承认接
受.一个应用软件就算没有链接也能很好的利
用它.因此,链接可以是暗示的也可以是明确
的.在这两种情况下,给定的应用程序并不一
定会利用这种链接.
HTML 2.0中的坎帕拉限定词应用
1996年5月W3C分布式索引和查询专题
组得出了一个未限定元数据应用规则.这个
规则指定了一个在HTML2.0中嵌入简单的
元数据的方法(并对元数据模式体系所采用
的参考应用提供链接).迄今已有一些模型
采用了这一规定,并把它进一步扩展以支持
带有限定词的元数据.
限定词的增加使句法问题变得更复杂了
.有两种方法可在HTML2.0中嵌入坎帕拉
限定词,每种都各有其优缺点.
第一种方法:Content超载法,即在
HTML2.0的句法中,使用META标签在
CONTENT中嵌入SCHEME LANGUAGE的信
息.例如:
这一方法最大的缺点是把Content字段和限
定词信息造成了混乱.
嵌入元数据的原因部分是为了使其更容易被
机器获取,而Content字段造成的困惑使这种方
法不能成为最佳方法.当然一个好的机器代理能
很聪明的处理Content属性并明智地使用(或忽
略)SCHEME和LANG标示符,但把这当成标准
显然是不切实际的.
第二种方法:附加特征法,在META标签
中应用额外的非正式属性(SCHEME和
LANG).例如:
这里的附加属性虽然不会引起很大的麻烦
,但可能会被网络上大多数的软件代理所忽
略,而有些代理服务器也不会确认这类
HTML,编辑软件对此的态度也不很明确,
并且还将存在一些潜在的问题.(编者按:实
际上这些限定属性在随后的HTML的发展中
都已成为正式属性词,因此后一种描述方法
成为DC嵌入在HTML中的常用描述方法.)
早期的限定DC元数据的应用要从这些优
点和缺点中进行选择.但随着网络体系结构
的发展,这些问题最终将得到解决.[DC-4]
DC-5 1997年10月,在芬兰首都赫尔辛基召开了
第五次元数据会议.
赫尔辛基会议最直接的工作是DC的十五
个未限定元素的定义的讨论尘埃落定.一直以
来DC的大多数元素都得到了广泛的无争议的
接受,但是其中仍有几个元素在含义和使用上
存在着分歧.这几个元素是日期,覆盖范围和
关联.
日期(Date)
日期这个元素在DC倡议的一开始就有问
题.在资源的生命周期中有很多重要的日期
.经过讨论后,代表们认为日期的原始含义
应该是:一个与资源创造或可获取性有关的
日期.尽管很多人认为这个概念仍很模糊,
但是限定的DC元素应用中的各种日期类型的
详细说明,也许会起到一点安慰作用.
关于详细的日期定义可从DC主页的
DATE页面中获得http://purl.oclc.
org/metadata/reports/date.这篇报告确定了一
些被认为是对元数据的应用非常重要的附加
的日期类型.
覆盖范围(Coverage)
Coverage元素在DC开始讨论时也是存在
问题的.该元素所包含的内容在第一次会议
上就展开了激烈的辩论.最后它可被理解为
资源知识内容的时空特征,其范围所包括的
资源可以是从以图象显示的地理参考(
geographically-referenced)数据到天文测量数
据集.关于覆盖范围元素的应用目的最后也
达成了共识,即为了支持资源的空间参考(
spatially-referenced).
用覆盖范围来确定一个时间段也是被允许
的,但这与DC中的日期(Date)元素是不同的.
另外,将来在覆盖范围中将加入更复杂的限定
体系方案.可以想象如一些邮政代码体系,人
体基因体系,或一个天体物理体系等,每一种
都是按不同团体的需要而设定的.
关联元素和1:1原则(Relation and the 1:
1 Principle)
即使是在传统的参考书目中,相关文献
间的复杂关系也很难进行一致的说明.在电
子领域,由于它其中充斥着更多的变量和翻
译,因此使这个问题变得更严重了.
一种关系的说明必须包括三个组成部
分.首先,是基础资源本身的鉴定(因为
基础资源是在元数据的标示符中鉴定的,
因此它无须在关联元素中出现).其次,
是目标资源的标示符.最后,必须有一个
已命名的关联来连接它们的.
未限定的DC元素的语义讨论在赫尔辛
基完成了(Finnish Finish).Finnish Finish将
成为第一个DC的正式标准基础,并为它的
广泛应用提供支持.
未限定的DC包括十五个元素(或它们
的子集),这十五个元素不含子元素,命
名域或其它限定词.尽管随着应用的增多
,最佳的实践标准也将有所发展,但未限
定的DC的词意还是稳定的.有关DC十五
各元素的定义可在http://purl.
org/DC/about/element_set.htm页面上查看
到.
DC的这十五个元素依据其所描述内容
的类别和范围可分为三组:
1.对资源内容的描述;
2.对知识产权的描述;
3.对外部属性的描述(instantiation).
资源内容描述类 知识产权描述类 外部属性描述类
题名( Title) 创建者(Creator) 日期( Date)
主题(Subject) 出版者(Publisher) 类型(Type)
描述(Description) 责任者(Contributors)格式(Format)
来源(Source) 权限管理(Rights) 标识(Identifier)
语种(Language)
关联(Relation)
覆盖范围(Coverage)
应用限定的DC在将来一段时间里还将
只是一种实验性的尝试.另外还存在着很多
问题,如怎样最好的处理扩充问题,怎样调
用体系和子元素限定词,以及怎样在互操作
性和更强的描述能力之间任何妥协.这些问
题的解决将从应用模型的进一步发展和在执
行项目的实际经验中找到答案.
子元素问题
随着未限定的DC的工作的结束,对于
限定词的说明有一种实质的要求.添加额外
的子元素(并使它们正式化)已成为一种共
识,这在一些项目应用中已经有所表现,用
子结构(substructure)来支持体系方案(
scheme)限定词,可望成为提高DC的精确
度的一种方式.DC-5在子元素问题,和用限
制的DC元数据支持更丰富词义所须的计划
方案方面取得了实质性的进展.主题组将继
续研究这些问题,而一些执行项目在这些未
知领域的研究则起了先锋作用.
DC与RDF的共同发展
在赫尔辛基,RDF的结构问题同样取得了
很大进展,它有望成为一个更强大的支持所
有元数据的结构.随着这一网络基础结构的
重要组成部分的成熟,它将逐步完善网络元
数据应用的解决方案.在HTML2.0中嵌入元
数据,以及支持HTML4.0的更复杂的元数据
仍是可行并有用的.然而,RDF模型不仅可以
嵌入元数据,还能支持更重要更复杂的元数
据模型.
RDF的进展将继续促进DC数据模型的发展
.使数据模型正式化将有利于解决现在DC团体
中的很多问题,包括1:1原则的执行,子结构(
体系方案和子元素)的一致表示,以及体系方案
和子元素的注册问题.
DC元素集和RDF框架是在W3C的资助下共
同发展起来的.DC为RDF提供了语义支持,而
RDF则证明了一个DC元数据数据模型基础的重
要性.尽管正式的DC数据模型工作没在这次会
议上完成,但它却能证明一个最好的把DC元素
(尤其是更复杂的,用体系方案加以限定的版本
)嵌入一个合理的结构的方法,以使其适应基于
网络应用的飞速发展所带来的挑战.
Z39.50
ZIG(Z39.50 Implementers Group)会议
也同意把十五个DC元素包含到Bib-1属性列表
中.这意味着,Z39.50的2版和3版用户将能
用DC元素来指定搜索.另外,还提议了怎样
让Z39.50的3版用户在查询中使用DC限定词
和计划方案.最终1998年6月的ZIG会议把DC
加入到了Bib-1属性列表中,并于1998年10月
重新进行了确认.
标准化问题
DC作为学科间的资源描述的首
要候选者,已得到了国际间的的广
泛承认.各执行项目之间的差异性
更突出了对于DC的显著需要,但是
如要让它适应更广阔的应用范围,
则须对它进行标准化,而DC团体已
开始朝这一方向努力.
未限定的DC是首先进行标准化的目标,它
已经过了近三年的激烈争论.这是一个独立的
既实用又相对稳定的集合,并有足够的执行经
验来证明它目前的良好状况.
对DC的首次正式修改是IETF(因特网工
程任务组)制定的一系列因特网草案,这些草
案将进行为期六个月的修改.
1. Dublin Core Metadata for Simple Resource
Discovery
用DC元数据进行简单的资源描述
2. Encoding Dublin Core Metadata in HTML
在HTML中应用DC元数据进行编码
3. Qualified Dublin Core Metadata for Simple
Resource Discovery
用限定的DC元数据进行简单资源描述
4.Encoding Qualified Dublin Core
Metadata in HTML
在HTML中用限定的DC元数据进行编
码
5.Dublin Core on the Web:RDF
Compliance and DC Extensions
网络上的DC:RDF的依顺和DC的扩
展
一旦这些文件的内容得到了认可,它
们将在IETF的RFC(Request forCommnets
)文件中被正式确认.RFC的文件都是正
式的标准并具有一定的资历.最后
RFC2413文件正式承认了Dublin Core在网
络信息描述中的地位.[DC-5]
DC-6
第六次元数据会议于1998年11月2-4日,
在美国的华盛顿特区举行.会议的主要议题
将是DC与其他资源描述方案之间的互操作性
.目前可以通过
http//purl.org/DC/workshops/dc6conference/inde
x.htm站点了解会议有关情况.
现在国际上有关Dublin Core 的研究已
进行得如火如荼,越来越多的项目都采用
了DC,有关各个DC执行项目的情况可从
http://purl.Oclc.org/docs/core/projects网页
上获得.在我们国内,中国国家实验型数
字式图书馆项目所采用的最小元数据集合
就是Dublin Core.
如果对Dublin Core有兴趣的话,不妨到http:
//www.ukoln.ac.uk/metadata/dcdot/站点上
去一趟.在这个站点里,你可以输入一个URL,
它将检索到这个页面并自动生成DC元数据,
或以HTML标签,或以RDF的形式,
在页面中的…部分嵌入元数
据.如有必要,生成的元数据还可被编辑成其
它的格式(USMARC,SOIF,IAFA/ROADS,
TEI headers,GILS或RDF).
四,XML的应用与发展
XML基础
HTML并不完美
HTML只是一种表达的技术.它并不一定
能揭示HTML tag中说揭示的含义.举一个最
简单的例子.Apple这句话在网络
浏览器中有特定的表现.但是HTML却并没有
告诉我们它倒底是什么.Apple只是一个英文
单词罢了.它在不同的环境之下可能会有不同
的意义.是一个计算机公司,一个水果,还是
一个姓氏 HTML并没有告诉我们Apple具体
的内容.
XML将会带来什么
SGML (通用标记语言标准ISO 8879:
1986)是HTML的前身技术.它是文件和文件
中信息的构成主体.SGML与HTML不同.
它允许用户扩展tag集合,允许用户建立一定
的规则.SGML所产生的tag 集合是用来描叙
信息段特征的.而HTML仅仅只是一个tag集
合.所以我们可以说HTML是一个SGML的子
集.
XML开发者源于SGML的设计和应用
者.他们已经在SGML上投入了大量精力
,但他们却发现SGML并没有完全发挥它
的作用.他们当然有其充分的理由.我们
可以列举以下几个重要方面给大家.在这
些方面SGML 带来的影响可以说是一场革
命.
对EDI的支持
EDI就是电子数据交换.它是网络发
展的一个主要目的市场.结构化信息的一
个主要目的就要使数据交换成为可能.不
同的工业都制定本工业统一的模型.就像
是不同的国家有着不同的语言,这便于本
国文化的交流.不同的工业内部信息用
统一的模型标识,便能方便和高效地共享
.
这样一个统一的模型就是DTD(文件类
型定义).当然DTD已经落伍了,它正被
XML的Schema(模式)所替代.很明显的,
网络是一个理想的电子数据的集散地.
在这里HTML是显然有缺陷的数据形式.
HTML不能完全表示不同工业中所需的不
同的令人满意的模型和它的语义.能不能
有一种新的语言来解决这个问题呢 答案
就是XML.
对Java 技术的帮助
Java 技术是本世纪最重要的技术发展之
一.Java 使浏览器工作时就像在通用的应用
平台上,而平台与平台之间却是独立的.但
固定的tag 集合和HTML语义上的贫瘠使得
Java的应用受到了极大的限制.正如前面提
到的,在HTML中不同的语义无法表现.故
数据元中丰富的信息得不到一种统一的表示
.
XML 却能完全胜任这份工作.
HTML页面要依赖网络服务器上的CGI脚
本来表现几乎每一个编程函数.这显然使服
务器工作量太大.有了XML和Java技术,更
多的应用软件处理起来将不占用多少网络通
信量.这使得网络更加快捷,客户可以同时
应用多个应用软件.
XML真正使得Java有了用武之地.
信息独立于平台之间
SGML作为HTML和XML的前身技术,
一直是一种平台之间互相独立的信息技术.
这便于指定信息语义的结构.当企业正忙于
展开各种各样的信息格式时(比如微软的RTF
,Adobe的PostScript和MIF,以及
WordPerfect,Lotus,Borland等公司的格式
),SGML已先人一步,确定立了一套严格一
致的,独立于平台之间表达信息的格式.
但在八十年代,正当SGML悄悄兴起时
,绝大多数工业上的计算机开发者都把目
光集中在新的计算机平台上.人们并没有
意识到多种私有信息格式可能带来的麻烦
.到了九十年代,网络技术的崛起之后人
们才清醒过来,试图寻找一种解决办法.
网络上的SGML
SGML已不适用于网络社会的需要."如
何使SGML能成功地运用于网络 ",这一问
题已自然而然地提上了议程.1996年8月,
GCA(图形通信协会)在Seattle召集SGML开发
者们举行了一次会议.会议由Sun
Microsystems公司的JonBosak主持.
论题集中于两大方向:
(1)在软件应用中HTML是一种不理想的信息
表现格式.
讨论的结果是有必要把SGML应用于网
络.
(2) SGML的某些方面已经落伍了.已成为了
它广泛传播的障碍.
讨论的结果是有必要考虑怎样修补
SGML.
既然SGML有着多重语义的tag集合,
它早就应出现在网络上了.而具有讽刺意
味的是,在1996年8月在网络上人们热衷
的却不是SGML,而是HTML和它的固定
的tag集合.
SGML开发者们立刻制定了一个紧急修
改SGML标准的方案.因为SGML是一个严
格而完整的系统,方便软件应用并不是它
的首要任务.所以在SGML中有许多语法语
义标准.它们既不方便而且消耗昂贵.它
们必须被修改或是删除.SGML开发者们
首先所作的工作就是得到一个SGML中可移
给网络的,非关键的结构信息的清单.他
们可以基于这个清单对SGML进行修改.
XML诞生了.
早在Seattle会议之前,Bosak和一些精心挑
选的SGML结构信息专家就已向W3C提出了"网
络上的SGML"计划.W3C支持并赞助了他们
的努力.工作于1996年7月正式开始起动.
工作的早期,有较大的阻力.因为也存在
反对SGML的人.一些制定XML标准的W3C代
表甚至声称"网络上的SGML"是不可能实现.
工作组(原称"SGML编辑审议委员会")并未退缩
.他们打算让SGML以全新的面目出现在网上
,给SGML以全新的面貌,故给它命名为"可扩
展标识语言",即XML.
工作组制定了一个雄心勃勃的计划
来展示XML特色的计划.计划的实施分
三部分:
(1)XML的句法.
(2)XLL(可扩展链接语言):XML 的语义
链接.
(3)XSL(可扩展类型语言):XML的表现
.
XML 1.0版本标准由W3C正式批准公布于
1998年1月10日.XLL和XSL的工作还正在进行.
XML的应用
最初XML的目标是让各种结构的文件都作为
统一的网络文件的一部分在网上传输.过去这些
文件是HTML实现的.HTML允许指定明确的元素
类型说明,比如特定的商品标号,文档标识,或
是可测量量的数值.和HTML 相比,XML允许客
户定义他们自己的文件元素集合,同时也可以指
示这些素元在屏幕上如何按指定的要求表现.
在早期,为了解决怎样在固定的目标之间传
输数据元,XML被定义为一种自然的编码形式.
在一些方案被考虑之后,一种被称
为RDF (资源描叙框架)的方案倍受亲睐
.RDF为XML提供了数据元编码定义
.这就像是一个公用的翻译器,为不同
的固定目标之间的数据提供翻译.
XML将支持更加专业的数据语言,比如
说OSD(开放软件描叙).OSD是由Microsoft
和Marimba提出的一种新的格式描叙语言.
在这种格式下,软件在网上能时时检查,
时时刷新版本.不是等用户自己更新,或
由是软件提供商提供类似的服务.当OSD镶
嵌于XML支持的CDF(频道定义格式)中时,
OSD更能使支持频道的桌面自动地更新.
正如前面提到的,XML的一个主要目标市
场是电子商务.传统EDI(电子数据交换)机制依
靠不同商业之间的强大计算机系统来实现压缩
的信息传输.每一条信息在传输使用,提供给
用户之前都必须编码.电子商务在网上运作时
用户端每填完一个HTML的表格之后,都要把
表格法还给初始的服务器处理.产品交易,谈
判签约,后勤管理,税收报表等等这一些活动
的数据处理都集中在了一端.可以预测到,有
了XLL所链接的行为控制机构和XSL所提供的
客户端评价功能,将来的数据可以从屏幕上抓
取,有必要的话可在客户端处理,在处理数据
时,传输给相关用户而不必要改换数据格式.
一个类似的协议是OTP(开放网络贸
易协议).它的草稿最初是于1998年1月
发布的.这个协议的制定是为了满足在
网上.消费者和销售者之间交易时消息
的传输.
它同时也允许第三方,比如说供货
商,市场评估机构,消费者保护机构等
,来参与使用.
XML的应用弥补了许多HTML的缺陷,
我们把它在网上的应用总结为四点:
1,当网络客户必须在不同的数据库之间传递
信息时的应用.
2,当需要把大部分从网络服务器载下的数据
在用户端处理时的应用.
3,当相同的数据对于不同的用户需要有不同
的界面时的应用.
4,当网络情报供货商要把发现的信息精心裁
减,并发送给不同的个人用户时的应用.
XML描述方法
描述,并不仅是指确认语义是否有效
.因为这意味着DTD或者schema的功能仅
仅是确认你的数据的结构是否有效.确认
语义是否有效确实是DTD和schema的一个
功能,但不是唯一的功能.DTDs和
schemas也能够定义数据的类型和数据间
的关系,这些甚至比语义有效性更有用.
因此我倾向于用描述这个词来解释DTDS
和schemas的功能.
让我们再回到上面提出的问题.因
为Web 上的数据处理者需要了解经过你
处理的数据的结构,同时也要了解你想
如何显示数据.举个如何用应用软件来
检查语义是否有效的例子,我可以用
IE5来检查我的文章,它支持XML的语
义有效性检查.
另外,详细描述你的数据可以给用
户提供很多帮助处理数据的信息.例如
,通过提供数据类型和ID/IDREF信息
,你可以减轻用户转换数据类型的负担
,能够提高数据通过相关节点的表现形
式.
什么是DTD
DTDs提供了定义文档规范的一种方法
.这是在W3C XML1.0说明书中描述的数
据描述的方法.下面我将给出关于DTDs相
关事实的一些简短的纲要:
DTDs描述XML文档.
DTDs可用来检查XML文档的语义有效
性和定义ID/IDREF关系.
DTDs使用尖括号,惊叹号,空格符,圆
括号,问号和星号来定义哪些元素和属性可以
使用以及它们能包含哪些内容.
DTDs能够为IE5所支持.
下面是个DTD的例子:
根据上面的DTD,下面的XML元素是有效
的:
9
什么是XML Schema
XML schema是用来描述XML元素和属性
的.它基本上包括属性和元素类型说明,可以
为XML元素和属性提供内容模块.
它很多情况下作用跟DTD差不多.但它的功能
要超过DTD.
随着IE5一起发布的MSXML分析器,支持
XML Schemas.
9
XML Schema与DTD有什么不同
最大的问题在于"什么时候我用XML
Schemas,什么时候我用DTDs "在什么情
况下用什么技术,你必须知道在短期内和长
期情况下哪样技术能给你最大的价值.在做
这样一个决定前,你需要了解这两种技术之
间的区别.
语法实例
XML Schemas是XML文档.不像DTDs
那样有自己的特殊语法,XML Schemas是用
XML写的.这给用户带来了三个好处.
1.你不需要知道两种语法来编写语法合
格的XML Schema.当然,你必须了解简化
XML数据
(XML-data Reduced)的语法规则.但是
,你不需要担心两套语法合格规则.
2.软件工具可以利用XML文档和
schemas之间语法通用这一优点为两者提
供支持.就好像对你来说掌握一种语法是
挺容易的,为一种语法建立支持也是挺容
易的.例如支持操作XML文档的分析器
也能用来操作schemas.不幸的是DTDs不
能以同样的方式操作.
3.为XML文档,XML schemas能够扩
展出去.你能向XML schemas中加入元素
和属性.只要元素和属性名域不同,它们
在一个schema中是合法的.
数据类型
DTDs允许你把内容类型定义为一个字
符串.XML schemas允许你把内容类型定
义为整型,浮点型,数据型,布尔型或者
许多其他的简单数据类型.在上面的例子
中,schema描述的B元素包括一个整数,
而DTD描述的B元素包括一个字符.
如果你想要编写一个应用软件来处理那
个元素的内容,并且需要那个元素的值为整
数,在DTD的例子中,你必须把它转化成一
个整数,而在schema例子中,你可以直接得
到那个整数值.
开放的内容模型
XML schemas支持开放的内容模型,这
意味着你在不违反语义有效性的情况下可以
扩充XML文档.请看下面的确XML例子:
TG/DT Latte
1
2.00
下面的DTD和schema能够用来描述这个例
子:
DTD:
schema:
>
如果上面使用schema的XML例子满足语义
有效性,你可以在元素中加入子元素,这也是
有效的,只要加入的元素在它们各自名域的前后
关系中是有效的.
TG/DT Latte
1
2.00
10:21 PDT
如果你想用上面的DTD检查元素的语义
有效性,将会得到有效性错误,因为
"myitem:time"不是用DTD定义的.
名域集成
XML Schema集成了名域,允许你把文
档中特殊的节点与schema中的类型说明联系
起来.联系XML节点和DTD的唯一方法是通
过DOCTYPE说明.这是有限的,因为每个
文档实例只能用一个DTD.多样的XML
schemas可用来描述一个XML文档,因为
XML Schema自身不描述XML文档,但它描
述XML元素.
XML结构
使用可升级的三层模型,XML可以从存
在的数据中产生出来.使用XML结构化的数
据可以从商业规范和表现形式中分离出来.
数据的集成,发送,处理和显示是下面过程
中的每一个步骤.我们看下图的总结:
数据结构,名域
XML名域允许开发人员在可识别的情况
下定义元素的名称,以避免同名元素间产生
冲突.在一个文档中使用的元素,比如购买
单,可以在不同的schemas中被定义.名域保
证元素名称不会产生冲突,并且阐明了各个
元素的来源,但是不能决定如何处理元素.
解析器必须知道每个元素的意义和如何处理
它们.
来源于不同名域中的标记可以混合在一起
,这是从不同来源过来的数据所必须具备的.
有了名域,元素既可以存在于相同的以XML为
基础的文档中,也可以存在于不同的schemas
中,说明唯一的语义.例如,在书店的购买单
上,一个"title"元素可以包含一个书名,另一
个"title"元素可以包含作者名.
名域只是针对元素名称.处理人员能
够定义元素的数据类型和内容的格式.
可以使用数据类型名域的dt属性来达到
这一目的.
1997-03-
17
W3C已经发布了XML的名域,允许元素
服务于URI.即使不同的作者选择同样的元
素名称,也不会辨识不清.随着任何人都能
发布自己的主页或者浏览他人的主页,名域
的功能允许使用者定义个人的术语字典或者
使用公布的公用名域.
Layman
Andrew
1997-03-17
1234567890
这段编码告诉读者如果一个元素是以
"dsig"打头,它的意义是由http://www.
dsig.org的名域所定义的.同样,
以"person"打头的元素的意义是由http:
//www.schemas.org/people的名域所定
义的.
名域保证元素名称不会冲突,也阐明
了元素是由谁定义的.它并不给出如何处
理元素的指令.读者仍然需要知道元素的
意义,并且决定如何处理它们.
在这里,"data"说明"sold-on"元素的内容
是按照标准格式的,这种格式是由数据类型
名域说明的.有了元素名称,处理人员终于
可以设计他们自己的数据类型,也能使用共
享的类型.微软正同W3C一起定义一套标准
类型,并且已经在IE5中提供部分支持XML
Schema的第一份数据类型清单.
XML数据发送,处理和解析
由于XML是开放的,基于文本的格式
,它可以通过HTTP像HTML一样传送.
桌面上的数据可以用DOM处理.代理商
将支持XML更新功能,使得中间层或数据
服务器上数据的变化可以传递给客户,反之
亦然.因此,代理商能够从客户端得到更新
的数据,并把数据传送到储存服务器上.
IE5中的XML解析器能够读入一串
XML数据,经过处理,产生一棵结构树,
并且使用DOM把所有数据元素作为对象
.解析器用CSS或XSL样式表显示数据,
或者用脚本把数据进行进一步的处理,或
者把数据移交给另外的应用软件或对象进
行进一步的处理.DOM用扩展方式支持
名域,数据类型,查询和XSL转化.
使用文档对象模式(DOM)处理和编
辑数据
DOM实际上是一个应用编程接口(
API),用来定义一种标准方法.通过这
种方法,开发人员能够处理XML结构树的
元素.对象模式控制着使用者如何同结构
树交流,并且把所有树的元素作为对象暴
露出来.
用HTML显示XML数据
XML文档自身不能决定如何显示
信息.XML数据只包含事实.HTML是
一个理想的显示语言.举个例子来说,
网上书店的店员可以访问主页寻找订单
.在后端,个人数据记录是用XML表
示的.但是,在前端,它们是用HTML
表示的.为了构造这个主页,Web服务
器和Web浏览器都需要把XML数据记录
转变为用HTML来表示.
数据捆绑和样式表可以用来把XML数据
组织成形象化的表达形式,并加上交互功能.
数据捆绑是动态HTML(DHTML)的一个
方面,它把单独的数据从信息源(例如XML
文档)移动到HTML显示上来,允许把
HTML作为显示XML数据的模块.微软把
XML数据源对象(XML DSO)作为IE5的一
部分.XML DSO能够在XML数据岛基础上
被调用.
XSL(可扩展类型语言)能够进一步加强这
一过程.一个XSL样式表包括如何从XML文档
中拿出信息以及如何把它转变为另一种格式的
指令.XML转变为另一种格式,比如HTML,
采用的是一种公布了的方法,这比采用脚本编
写简单而且容易理解.另外,XSL把XML作为
它的语法,使XML的编写者不用去掌握另外的
标识语言.
CSS仍然被应用于结构简单的XML数据,并
CSS不提供与数据源结构不同
XSL,可以产生与原来的
数据结构完全不同的表达结构.如下所示.
XSL提供内容和表现形式的语义和结
构独立性.
增加HTML
给HTML页增加语义信息并不容易.
很多程序曾经试图用一些非标准的方法来
解决这一问题,比如在HTML注释中隐藏
数据.但是,这样的注释是很难使用的,
对象模式并不能理解它们.
为了解决这一问题,W3C定
义了一个格式,用来把基于XML
的数据放到HTML页中.通过使用
数据岛(data islands),扩展
HTML允许很大范围的应用软件使
用HTML作为主要文档和显示格式
,并且使用这些文档中内含的
XML保存数据.
一个HTML页包含有关这一页主题
的特殊数据.例如,如果这一页显示
一位作者最近一部小说的广告,这一
页也包括有关这本书的XML数据,比
如ISBN序号,出版者或者是价格.这
些信息显不显示并不重要,重要的是
这些信息作为数据可被获得和理解.
转换和查询XML
随着XML作为在Web上交换数据的一
种标准方式的出现,不可避免地种种需要
就会产生,比如查询XML,制作压缩数据
,对数据分类和过滤以及转换XML语法.
XSL和XSL模式语言提供了满足这些需要
的一种方法.
XSL模式是简明的语法用来识别XML
文档的节点,建立在节点类型,名称,内
容和与树中其他节点相关的前后联系的基
础上.
XSL提供了一种语法,使XSL模式查询
的结果与模板有关,使XML源文档中的数
据具体化.XML语法可以输出,以供分类
和过滤,或者把一个schema中的数据转化到
另一个schema中去.
W3C正考虑开发出更强大的查询语言
,但开发小组还没有建立.
设置字符和编码
XML中的信息都是用统一的字符编码标
准编写的.包括元素的内容和名称.因此
XML支持所有的国际字符的表现形式.
统一的字符编码标准可以直接转换为16
位字符,但更通常的是把它转换为方便使用
的或者是简化的某种语言的编码.XML支持
广泛的编码,只要一个文档中使用同一种编
码.
空格符
不同于HTML在多数情况下忽略
空格符,XML是针对数据的,因此通
过xml:space属性可以保留空格.例
如,下面两种情况是不同的:
Tchaikovs
ky's First Piano
Concerto
Tchaikovsky's
First Piano Concerto
在IE5中xml:
space="default"这一取值在标记
间加入了一些装饰用的空格符.
远程调用SOAP
SOAP(Simple Object Access Protocal)
技术有助于实现大量异构程序和平台之间
的互操作性,从而使存在的应用能够被广
泛的用户所访问.SOAP是把成熟的基于
HTTP的WEB技术与XML的灵活性和可扩
展性组合在了一起.
HTTP是一个相当有用的RPC协议,它
提供了IIOP或DCOM在组帧,连接管理以
及序列化对象应用等方面大部分功能的支
持.(而且URLs与IORs和OBJREFs在功
能上令人惊叹的接近).HTTP所缺少的
是用单一的标准格式来表达一个RPC调用
中的参数.这则正是XML的用武之地.
象NDR和CDR,XML是一个与平台
无关的中性的数据表达协议.XML允许
数据被序列化成一个可以传递的形式,使
得它容易地在任何平台上被解码.XML
有以下不同于NDR和CDR的特点:有大
量XML编码和解码软件存在于每个编程
环境和平台上
XML基于文本,相当容易用低技术水平的
编程环境来处理.XML是特别灵活的格式,
它容易用一致的方式来被扩展为支持可扩展
性,在XML中每一个元素和属性有一个名域
URI与它相联系,这个URI用xmlns属性来指
定.
考虑下面的XML文档:
Hello, World
This is a comment!!
元素和的名域
URI是urn:schemas-develop-com:
StringProcs.
元素的名域URI是
http://foo.com/documentation.
第二个URI也是一个URL的事实是不重
要的.
在这两种情况下,URI简单地被用来消
除元素,,
和任何碰巧有同样标记名的其它
元素间的歧义.
后面的形式对作者来说更容易,尤
其是如果有许多名域URIs在使用时.
XML也支持带类型的数据表达.正
在推出的XML Schema规范为描述XML
数据类型标准化了一个词汇集.下面是
一个元素的XML
Schema的描述:
这个XML Schema定义阐述了XML名
域urn:schemas-develop-com:
StringProcs包含了一个名为
的元素,这个元素包含了
一个名为string1的子元素(类型为
string),它被0个或更多没有指定的元素
所遵守.
XML Schema 规范还定义了一组内置
的原始数据类型和建立一个XML文档中
元素的类型的机制.
下面的XML文档用XML Schema类型属
性来把元素和类型名联系在一起:
Don Box
23.5
连接XML文档事例到XML Schema描述
的新的一个机制在本文写作的时候正在标准
化过程中.
HTTP + XML = SOAP
SOAP把XML的使用代码化为请求和
响应参数编码模式,并用HTTP作传输.
这似乎有点抽象.具体地讲,一个SOAP
方法可以简单地看作遵循SOAP编码规则
的HTTP请求和响应.一个SOAP终端则可
以看作一个基于HTTP的URL,它用来识
别方法调用的目标.象CORBA/IIOP一样
,SOAP不需要具体的对象被绑定到一个
给定的终端,而是由具体实现程序来决定
怎样把对象终端标识符映射到服务器端的
对象.
SOAP请求是一个HTTP POST请求.
SOAP请求的content-type必须用text/xml.而
且它必须包含一个请求-URI.服务器怎样解
释这个请求-URI是与实现相关的,但是许多
实现中可能用它来映射到一个类或者一个对
象.一个SOAP请求也必须用
SOAPMethodName HTTP头来指明将被调用
的方法.简单地讲,SOAPMethodName头是
被URI指定范围的应用相关的方法名,它是
用#符作为分隔符将方法名与URI分割开:
SOAPMethodName:urn:strings-
com:IString#reverse
这个头表明方法名是reverse,
范围URI是urn:strings-com:Istring
.在SOAP中,规定方法名范围的
名域URI在功能上等同于在DCOM
或IIOP中规定方法名范围的接口ID
.
简单的说,一个SOAP请求的HTTP体是一
个XML文档,它包含方法中[in]和[in,out]参数
的值.这些值被编码成为一个显著的调用元
素的子元素,这个调用元素具有
SOAPMethodNameHTTP头的方法名和名域
URI.调用元素必须出现在标准的SOAP
和元素内(后面会更多讨
论这两个元素).下面是一个最简单的SOAP
方法请求:
POST /string_server/Object17 HTTP/1.1
Host:209.110.197.2
Content-Type:text/xml
Content-Length:152
SOAPMethodName:urn:strings-com:
IString#reverse
Hello, World
SOAPMethodName头必须与下的
第一个子元素相匹配,否则调用将被拒绝.
这允许防火墙管理员在不解析XML的情况
下有效地过滤对一个具体方法的调用.
SOAP响应的格式类似于请求格式.响
应体包含方法的[out]和[in,out]参数,这个
方法被编码为一个显著的响应元素的子元素
.这个元素的名字与请求的调用元素的名字
相同,但以Response后缀来连接.下面是对
前面的SOAP请求的SOAP响应:
200 OK
Content-Type:text/xml
Content-Length:162
dlroW,olleH
这里响应元素被命名为
reverseResponse,它是方法名紧跟
Response后缀.要注意的是这里是没有
SOAPMethodName HTTP头的.这个头只
在请求消息中需要,在响应消息中并不
需要.
图6 与其它ORPC 请求的对应
图7 其它ORPC对象引用
图6和图7表明SOAP是怎样与以前讨论
的ORPC协议相互对应的.让许多SOAP新
手困惑的是SOAP中没有关于SOAP服务器
怎样使用请求头来分发请求的要求;这被
留为一个实现上的细节.一些SOAP服务器
将映射请求-URIs到类名,并分派调用到静
态方法或到在请求持续期内存活的类的实
例.
其它SOAP服务器则将请求-URIs映射到
始终存活的对象,经常是用查询字符串来编
码一个用来定位在服务器进程中的对象关键
字.还有一些其它的SOAP服务器用HTTP
cookies来编码一个对象关键字,这个关键
字可被用来在每次方法请求中恢复对象的状
态.重要的是客户对这些区别并不知道.客
户软件只是简单遵循HTTP和XML的规则来
形成SOAP请求,让服务器自由以它认为最
合适的方式来为请求服务.
五,资源描述框架(RDF)
1997年十月,W3C正式发布了RDF的草案
.RDF(Resource Description Framework),
即资源描述框架,已不仅仅是简单的一个元数
据方案,而是一个能对结构化的元数据进行编
码,交换及再利用的体系框架.这种体系结构
通过对通常意义上的语义,语法和结构的支持
,从而提供了在各种不同的元数据体系之间的
互操作性.RDF本身并不对各种不同的元数据
进行语义定义,而是提供一种框架体系,使不
同的用户或团体能够在这一框架下定义他们自
己的元数据的元素.
RDF采用XML(eXtensibleMarkup
Language,可扩展标记语言)作为交换和处
理元数据的通用语法结构体系.XML提供
了与供应商无关的,可由用户扩展,认证的
标记语言体系,它既提供了可读性,也有表
达复杂结构的能力.RDF利用了XML严谨
的结构,避免了语义上的二义性,从而为元
数据的编码,交换及机器自动处理提供了保
证.RDF通过一个简单而又功能强大的数据
模式,支持在各个不同的元数据语言之间的
模块化的互操作能力.
RDF的字符集以Unicode(ISO/IEC
10646)为标准,在Unicode编码定义上
是相同的两个字符串描述即被RDF认定
为是相同的字符串.
基本RDF模型
RDF是表示对象的命名属性及其值的数
据模型,这是从各种数据表示方式中抽取出
来的.RDF属性可以想象成资源的的某一特
性并对应着特性-取值对.RDF属性还可以
表示出资源之间的关系,因此一个RDF模型
可以看成是一个实体关系图(ER).在面
向对象的设计中,资源对应对象,属性对应
实例变量.
基本的数据模型包含三种对象类型:
资源:在RDF表达式中被描述的所有
东西称为资源.一个资源可以是一个WEB
页的入口,如HTML文件
http://w3.org/Overview.html,一个资源可以
是一个WEB页的部分,即文档中特定的
HTML或XML元素.
一个资源也可以是网页的总和,即网
站.一个资源同样可以是无法通过WEB访
问的的对象,如一本打印的书籍.资源一
般是通过URI加上附加的anchorID来命名
.
属性:属性是用来描述资源的特定的特点,
品质或关系.每个属性具有特定的意义,定义
其允许的取值,可描述的对象类型以及和其他
属性之间的关系.
声明:一个资源和其命名的属性加上该属
性的取值就是一个RDF声明.这个声明的三个
对应部分叫做:主题,谓语和对象,声明的对
象可以是另一个资源或一个简单的字符串或其
他XML定义的数据类型.
举例
考虑这样一句话:
Ora Lassila is the creator of the resource http
://www.w3.org/Home/Lassila
这句话可以变成如下三个部分:
Subject (Resource)http://www.w3.
org/Home/Lassila
Predicate (Property)Creator
Object (literal)"Ora Lassila"
这里可以画出上面RDF声明的示意图:
Figure 1:Simple node and arc diagram
现在来考虑我们表达更多的信息,例如:
The individual whose name isOra Lassila, email
, is the creator of http:
//www.w3.org/Home/Lassila
这句话的目的是将Creator属性的赋值变
成一个结构化的实体.在RDF中这样的实体
可以是另一个资源.上句中并没有给出该资
源的名称;它是匿名的,所以在下图中用空
白的椭圆表示:
:Property with structured value
注意:上面可以读为:"http://www.w3.
org/Home/Lassila has creator something and
something has name Ora Lassila and email
lassila@w3.org".
上例的结构化实体也可以被赋予唯一标识
符,这由应用数据库设计这选定.假设命名为
"person"资源,识别的URIs 可以类似为:http
://www.w3.org/staffId/85740.
现在我们可以将句子写为如下:
The individual referred to by employee id
85740 is namedOra Lassilaand has the
email addresslassila@w3.org.The
resource http:
//www.w3.org/Home/Lassilawas created
by this individual.
RDF模型为:
Figure 3:Structured value with identifier
RDF语法
RDF模型只是规定了定义和使用元数据的
抽象的和概念性的框架,而在创建和交换元数
据时必须应用某种具体的语法,RDF规定使用
XML作为其语法.
比如上节中的例子:
Ora Lassila is the creator of the resource http:
//www.w3.org/Home/Lassila
用RDF/XML可以描述如下:
Ora Lassila
容器(Container)
有时会描述一组资源,如一件工作由
多人完成,或一个班上的学生,或者一个
软件包中的模块.RDF用容器来描述这样
的一组资源.
容器的对象有三种:
包(Bag):资源的无序列表.一
般用来表达一个属性的多值,但顺序并
五意义
序列:资源的有序列表,用于表示
多值并有序的情况
可选择:对于属性值的可选择资源
列表,可以用来表示工作名称的替代语
言翻译,或者资源的镜像站点等.
RDF用以上三种对象来声明一种资源来
表示一组资源列表,其二者关系用一组简单
的"_1", "_2", "_3"属性定义来表示.例如,
表示:
The students in course 6.001 are Amy, Tim,
John, Mary, and Sue
其RDF模型如下:
Bag容器并非将同类属性进行重复,如句子:
The source code for X11 may be found at ftp.x
.org, ftp.cs.purdue.edu, or ftp.eu.net
其RDF 模型是:
可选择容器一般用于语言标签的关联,例
如标题属性可以指向一个可选择容器,其中
存储着该标题名称的各国语言翻译.
关于声明的声明
除去资源需要声明,RDF还对声明
本身进行了定义,成为高一级的声明
.为此,我们建立了声明的模型,它
包括如下几种对象:
主题:主题属性是用模式化的声明描述资
源,及所描述的资源是什么(在例
子中是:http:
//www.w3.org/Home/Lassila)
谓语:谓语属性标识声明中的原始属性的
值(例中是:creator)
对象:对象属性标识声明的属性的值(例
中是:Ora Lassila)
类型:类型的值表示新资源的类型.所有
的声明的类型值为RDF:Statement
一个RDF声明可以用下面的图表来描述:
Ora Lassila is the creator of the resource http:
//www.W3.org/Home/Lassila
读做:o is the value of p for s 或s has a property
p with a value o 甚至the p of s is o 例如下句:
如图一所示的关系,其三个要素{p, s, o}
为:
{creator, [http://www.w3.org/Home/Lassila], "Ora
Lassila"}
也可以表示这个新资源X如下:
{type, [X], [RDF:Statement]}
{predicate, [X], [creator]}
{subject, [X], [http://www.w3.
org/Home/Lassila]}
{object, [X], "Ora Lassila"}
在每一个RDF描述中,属性类型以
及任何对属性值的特性及限定都将由一
个或更多的体系(schema)来进行定义.
在同一个描述中的属性类型定义应来自
同一体系.每一个体系应由URI来进行
声明.这个URI仅仅作为指明这一体系
的标识或指向一个机器可读的体系描述.
原理上来说,理解了一个RDF描述所使
用的体系也就是理解了RDF描述中每一个
属性的准确语义内涵.同时,一个并不能
理解特定体系的应用程序仍然能够处理
RDF描述,例如将属性类型及属性值抽取
出来转入另一个程序或缓存中.
有关RDF详细的定义参见其官方网页
:http://www.w3.org/TR/PR-rdf-syntax/
六,数字图书馆结构的设计
信息的组织
通过上面章节的讨论,我们可以基本确
立数字图书馆系统资源的描述模式:采用
Dublin Core定义的元数据,通过XML对图书
资源进行描述.
下面以《中华文化通志》电子资源的书目,
给出其XML形式的实例:
Dublin Core形式书目
中华文化通志
萧克
书同文电
脑技术开发有限公司
中国文化
中华文化
本书是由中华炎黄文化研
究会会长萧克将军主持编纂,由全国百余位
专家和学者通力撰写的一部大型文化专志.
全志分《历代文化沿革》,《地域文化》,
《民族文化》,《制度文化》,《教化与礼
仪》,《学术》,《科学技术》,《艺文》,
《宗教与民俗》,《中外文化交流》十典.
每典十志,共一百卷,约三千六百万字;以
齐全的门类和浩繁的卷帙,全方位,多视角
地记述了以汉文化为主体的包括全国五十五
个少数民族在内的上下五千年灿烂文化.是
迄今为止中国第一部全面,系统地记述中华
文化的巨著.
上海人民出版社
上海人民出版社
1998-10-
大型文化专志
电子图书(eBook),源数据所站空
间:5G
7208022542
迪志文化出版有限公司
http://www.dheritage.com
chi
书同文电脑技术开发有限公司
http://www.unihan.com.
cn
中国古今文化(公元前26世
纪——公元20世纪)
上海人民出版社
……
……(另一条书目)
……(另一条书目)
说明:
这是一个仅表示文档结构和数据结构的
XML标记形式,即未标识数据显示和打印时所
使用的字号(体)以及排版格式.这种形式仅
供系统处理用.因为XML是可以将信息的存贮
与显现分开的.书目数据的显现格式可通过另
外的应用程序实现.
前六行为文档的定义部分.
第七行开始至第一个
结束,为《中华文化通志》这条书目标记.
其后的……为其余各条书
目标记,此处省略.
XML对元数据的标记信息不需人工录入
,完全可以通过各项数据录入格式自动置标
.因而它比MARC(机读目录)形式数据输
入标引更为简单.
书目信息与全文版电子资源的链接是通
过……,或 实现
的.
每项元数据是可重复标记的,数据是可
以变长的.
系统结构
采用XML编写的元数据定义后,方便
地支持了信息的查询和管理,同时对于异
地资源的分布式调用,可以通过代理服务
器的VDB服务,向用户屏蔽数据的查询,
使得用户感觉不到因数据存放的分散而带
来的不便.
同时要求数据加工系统必须按照元数
据的定义对图书资源进行加工,并生成相
应的元数据索引.
数字图书馆的信息对象结构图如下所
用户
数字对象
元 数 据
数字对象
元 数 据
数字对象
元 数 据
图书杂志图片录音录像缩微
加工
符合RDF的分布资源传统资源
VDB
XML
XML
XML
北京上海广州
代理服务器
·上一篇：大陆通讯产业与市场No3
·下一篇：*仅供识别