都柏林核心元数据发展简史(下)_元数据论文

都柏林核心元数据发展简史(下)_元数据论文

都柏林核心(Dublin Core)元数据发展简史(下),本文主要内容关键词为:都柏林论文,简史论文,核心论文,数据论文,Dublin论文,此文献不代表本站观点,内容供学术参考,文章仅供参考阅读下载。

主持人 刘炜

由于上期连载的原因,本期现代化之路栏目的主题依然是“数字图书馆”。两年前曾与一位学长讨论这样一个问题:“数字图书馆离我们中国有多远?”两年来发现许多ICP (网络信息内容提供商)都在做“数字图书馆”,许多ISP(网络信息服务提供商, 如各地电信部门)在极力拉拢各地图书情报机构做“数字图书馆”,同时突然发现图书馆的许多观念和技能正好可以用在网络信息资源的组织和传播上,元数据就是生动一例,英雄大有用武之地了。

上期我们提出这样一个观点,广大的基层图书馆不应在数字时代到来之际无所事事,“大家上网去!”上网是建设数字图书馆的第一步。上网不仅能使自己的资源和服务更加贴近读者,而且能真正使各类图书馆连片成网,显示整个图书情报事业的生机。本期除了元数据标准的继续讨论外,另外刊载了一篇张丹阳同志的文章,利用一种社会学方法,审视我们的数字图书馆建设。

DC-3

1996年9月24-25日,美国网络信息联盟(CNI)和OCLC在俄亥俄州Dublin组织召开了第三届元数据研讨会,会议专门就网络环境中图像的描述和图像数据库等问题进行了讨论。与会专家来自计算机学、图书馆学、联机信息服务、地理信息系统、博物馆和档案馆、医学等各个学科领域,探讨了网络图像资源的描述问题,希望能够推进网络图像及图像数据库资源的标准和协议的发展。

目前因特网上的数字图像种类十分丰富, 包括从图画和建筑图到CAT扫描图,从X光片到星球地表图和天文物体图。本次研讨会的讨论对象主要集中静止图像,如图形、幻灯和照片图像。而动态的图像,如电影,录像之类都不在考虑之列。DC希望能够涵盖所有学科对图像和图像库的一般要求,涉及艺术、建筑、机械工程、医学、生命及社会学等众多领域。

第三次的研讨会达成了一种共识,即认为DC在Warwick框架中, 能够成为网络环境中对于图像进行简单资源描述的基本模型。

图像到底有什么不同之处?

在第一届的元数据研讨会上定义的DC 最初是用来描述文本对象(DLO:Document Like Object)的。 现在为了描述网络上的数字图像, 有必要把DC做一些修改,以使它能适应图像描述的要求。那么,图像与DLO到底有什么不同呢?

首先,图像文件通常有一定的格式,对同样的图像进行两次数字化,计算机看来通常是完全不一样的,其编码要求严格得多。而文本文件的表现形式要更少一些。其次,文本材料很容易建立索引,这通常能简化或使描述工作自动化,而图像的大部分描述元素不可能自动索引。最后,检索图像对于时间与带宽的要求通常都是很高的。

随着因特网上复杂图像的运用越来越多,元数据在图像的发现和选择方面发挥越来越重要的作用。表示这些图像所必须的信息包括:

·种类(位图,矢量,视频)

·格式(TIFF,GIF,JFIF,PICT,PCD,EPS,CGM,TGA等)

·压缩策略和比例(JPEG,LZW,QuickTime)

·动态范围

·色彩查找图表和相关尺度(metrics)(CMYK,RGB等)

充分捕捉这些信息,并对它们进行编码与DC最初的设计目的:简约形成了矛盾。如果DC被用于图像领域中,它就必须确定一个可扩展的机制,来支持如前所述的图片所需的更丰富的描述符的编码。

DC元素的修订

在第三次元数据会议中对DC的几个元素进行了修改,以使它们不至于太以文本为中心。另外还在原来十三个元素的基础上又新增加了两个元素:Description和Rights。

1.描述(Description)

Description与Subject分为两个独立的元素,因为图像专家认为它们对于图像来说是两个截然不同的概念。

这样,

Subject可以包括关键字,

主题词和分类号等。

而Description则用于图像方面的描述性文字或内容描述, 并包括文本文件下的摘要。

2.权限管理(Rights Management)

权限管理字段被认为是一个核心描述记录的必要组成部分。它对于描述图像尤为重要,因此如果不包括这一元素,将影响DC在图像领域的广泛应用。

3.桥接DC与其他元数据集

第一届元数据会议的一个直接成果是由美国国会图书馆

Rebecca Guenther提出的桥接DC元素和MARC字段的方案。这项研究使大家意识到DC可作为网络资源描述的一个基础模型,反过来影响对于MARC的认识。

类似的DC元素与现有的图像描述标准之间的桥接,使DC在图像处理中起了中介作用。正如专题组所建议的,现有的标准和实践可作为指导,可以减少提出一套新的描述标准所必须的工作。

DC-4

1997年3月3-5日, 第四届元数据会议在澳大利亚首都堪培拉召开。本次会议由OCLC(The Online Computer Library Center), DSTC (the Distributed Systems Technology Centre ), 和NLA (theNational Library of Australia)倡议召开。

本次会议最直接的结果就是产生了两大学派:最小主义学派和结构语言学派。

最小主义学派指出DC的最主要特征是它的简约性。这种简约性对创造元数据(如由对编目技术不很熟悉的作者)和利用工具(如对细节的限定词或编码策略起的作用不大的索引引擎)来使用元数据是非常重要的。只有当一个简单的核心元素在各种情况下所蕴涵的意义都相同,才能达到在各团体间的语义互操作性这一目的。附加的限定词能指定、修正并详细说明元素的含义。由于这些将在不同的时间由不同的集团以不同的方式来完成,因此在元素的语义方面也许会出现变化,这在一定程度上会影响语义互操作性。

结构语言学派也意识到了在更灵活的正式的扩展和限定元素交换方面会出现元素语义变化的危险。但却认为最重要的是元数据内容的限定能力。

DC-4正式确定了附加的DC限定(堪培拉限定), 它们分为三类:语种描述(LANG)、模式体系(SCHEME)和属性类型(TYPE)。

语种描述(LANG)

这一限定指定了元素值的描述字段的语言,而不是资源本身的语言。由于网络上的多种语种问题越来越突出,这个限定词也变得越来越重要。迄今为止,英语被假定为是网络上的语言,但这一现象正在改变,确定资源本身和资源描述的语言问题变得极为重要。

模式体系(SCHEME)

SCHEME限定用来确定给定元素的遵从已有的或正在讨论中的一个体系结构中的合法值,如分类表、专题词或各类代码表。 如一个Subject字段可以是一个体系限定为LCSH(

Library of Congress SubjectHeading)的数据。SCHEME 限定对应用软件或应用人能提供一个处理线索,以使被限定元素能更好的使用。然而在其它情况下SCHEME标示符对字段的使用、日期的翻译都非常重要。

属性类型TYPE(Sub-element Name)(子元素名)

这个限定词指定了给定字段的一个方面。它的用途是缩小字段的语义范围。它同样可被看作是一个子元素名,TYPE限定词改正的是元素的名称,而不是元素字段的内容。TYPE是DC限定词中争论最大的词。在明确定义可接受的类型以及怎样定义上有一些逻辑困难。在某种意义上,它不是一个限定词,而是元素名本身的一个子集。

把元数据结构与特许命名域代理联系起来

限定词可以是受控制的命名域的一部分,命名域可以是任意指定的。在联机环境中,可以通过超链来完成。例如:DC.TTTLE是DC元数据元素集中的一个元素名,在这里DC就是一个特许命名域,一般需要有一些团体负责对这一命名域中的内容进行解释。如LCSH是一个体系(SCHEME)的名字,它也是一个命名域,它的解释责任主体是美国国会图书馆。

解释责任机构不一定非要有链接。例如,SCHEME为LCSH时,如果美国国会图书馆不提供解释,链接也能起到解释的作用,因为LCSH的标示符为图书馆界所共知,具有一定的可信度,一个应用软件就算没有链接也能很好的利用它。

HTML2.0中堪培拉限定的应用

1996年5月W3C分布式索引和查询专题组提出一个非限定性元数据应用规则。 这个规则指定了一个在HTML2.0中嵌入简单的元数据的方法, 并对元数据模式体系所采用的参考应用提供链接。迄今已有一些模型采用了这一规定,并把它进一步扩展到支持限定性元数据的应用。

限定的增加使句法问题变得更复杂了。有两种方法可在HTML2.0 中嵌入堪培拉限定,每种都有其优缺点。

第一种方法:Content负载法,即在HTML2.0的句法中,使用META标签在CONTENT中嵌入SCHEME LANGUAGE的信息。例如:

〈META NAME="DC.Subject"

CONTENT="(SCHEME=LCSH)(LANG=en)

Computer Cataloging of

Network Resources"〉

这一方法最大的缺点是把Content 字段与限定词信息造成了混乱。嵌入元数据的部分原因是为了使其更容易被机器获取,而Content 字段造成的困惑使这种方法不能成为最佳方法。当然一个好的程序应能很聪明的处理Content属性并明智地使用( 或忽略)SCHEME和LANG标示符, 但把这当成标准显然是不合适的。

第二种方法:附加特征法,在META标签中应用额外的非正式属性(SCHEME和LANG)。例如:

〈META NAME="DC.Subject""SCHEME="LCSH"

LANG="en"

CONTENT="Computer Cataloging of Network Resources"〉

这里的附加属性虽然不会引起很大的麻烦,但可能会被网络上大多数软件所忽略,而有些软件解释器也不会确认这类HTML,编辑软件对此的态度也不很明确,并且还将存在一些潜在的问题。(编者按:实际上这些限定属性在随后的HTML的发展中都已成为正式属性词,因此后一种描述方法成为DC嵌入在HTML中的常用描述方法。)

限定性DC元数据应用要从这些优点和缺点中进行选择。但随着网络体系结构的发展,这些问题最终将得到解决。

DC-5

1997年10月,在芬兰首都赫尔辛基召开了第五次元数据会议。

赫尔辛基会议最直接的成果是DC的十五个非限定元素定义的讨论最终得以尘埃落定。长期以来DC的大多数元素都得到了广泛的认同和接受,但是其中仍有几个元素在含义和使用上存在着分歧。这几个元素是日期、覆盖范围和关联。

日期(Date)

日期这个元素在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)

即使是在传统的参考书目中,相关文献间的复杂关系也很难进行一致的说明。在电子领域,由于它其中充斥着更多的变量和对应,因此使这个问题变得更严重了。

对于那些从别的资源中抽取出的本身也有自己的元数据的资源来说,要提供一个连贯一致的元数据就更困难了。而这对于图书馆和博物馆来说却是一个基本要求。这个问题在赫尔辛基也成了一个讨论的重点。讨论的结果是最后得出一个1∶1原则——即每个资源都要有一个分立的(discrete)元数据描述,而每一个元数据描述所包含的元素必须与一个单独的资源有关联。能把这些描述以连贯一致的样式连接起来是令人满意的。关联元素即为这种连接提供了一个合理的方式。用关联把元数据和资源连接起来的这种方式,对其它元素的应用同样有用,而其副作用在现实应用中还不得而知。

一种关系的说明必须包括三个组成部分。首先,是基础资源本身(因为基础资源是在元数据的标示符中明确的,因此它无须在关联元素中出现)。其次,是目标资源的标示符。最后,必须有一个已命名的关联来连接它们的。

非限定性DC元素的语义问题在赫尔辛基会议已达成一致,称为芬兰结论(Finland Finish)。芬兰结论是第一个DC的正式标准。

非限定性DC包括十五个元素(及它们的子集),这十五个元素不含子元素,命名域或其它限定。尽管随着应用的增多,最佳的实践标准也将有所发展,但非限定性DC的词意还是稳定的。有关DC十五个元素的定义可在http://purl.org/DC/about/element-set.htm 页面上查看到。

DC的这十五个元素依据其所描述内容的类别和范围可分为三组: 1.对资源内容的描述;2.对知识产权的描述; 3.对外部属性的描述(instantiation)。

资源内容描述类知识产权描述类 外部属性描述类

题名(Title) 创建者(Greator)日期(Date)

主题(Subject)出版者(Publisher) 类型(Type)

描述(Description) 责任者(Cmtnbutois)格式(Format)

来源(Source) 权限管理(Rights)

标识(Identifier)

语种(Language)

关联(Relation)

覆盖范围(Coverage)

应用限定性DC在将来一段时间里还将只是一种实验性的尝试。另外还存在着很多问题,如怎样最好地处理扩充问题,怎样调用体系和子元素限定词,以及怎样在互操作性和更强的描述能力之间进行妥协。这些问题的解决将得益于应用模型的进一步发展,以及在具体的实践经验中找到答案。

子元素问题

随着非限定性DC工作的结束,对于限定进行说明有了现实要求。添加额外的子元素(并使它们正式化)已成为一种共识,这在一些项目应用中已经有所表现,用子结构来支持体系方案(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 ResourceDiscovery

用限定性DC元数据进行简单资源描述

4.Encoding Qualified Dublin Core Metadata in HTML

在HTML中用限定性DC元数据进行编码

5.Dublin Core on the Wed:RDF Compliance and DC Extensions

网络上的DC:兼容RDF及DC的扩展问题

一旦这些文件的内容得到了认可,它们将在IETF 的RFC (Requestfor Commnets)文件中被正式确认。RFC 的文件都是正式的标准并具有一定的资信。最后RFC2413文件正式承认了Dublin Core在网络信息描述中的地位。

DC-6

第六次元数据会议于1998年11月2-4日,在美国的华盛顿特区举行。会议的主要议题是DC与其他资源描述方案之间的互操作性。目前可以通过http://purl.org/DC/workshops/dcoconference/index.htm站点了解会议有关情况。

现在国际上有关Dublin Core的研究已进行得如火如荼, 越来越多的项目都采用了DC,有关各个DC执行项目的情况可从 http://purl.oclc.org/docs/core/projects网页上获得。在我们国内,中国国家实验型数字式图书馆项目也已原则同意采用DC作为最小元数据集合。相信随着这一项目的进一步开发和实施,Dublin Core将逐渐为国内所熟悉,并随之带动起国内的研究和应用。

如果对Dublin Core的应用有兴趣,可以访问http://www.ukoln.ac.uk/metadata/dcdot/站点,在这个站点里, 如果你输入了一个URL地址, 它将检索到这个页面并自动生成DC 元数据, 你可以选择以HTML〈META〉标签,或以RDF的形式,在页面中的〈HEAD 〉…〈/HEAD〉部分嵌入元数据。如有需要,生成的元数据还可被编辑成其它的格式(USMARC,SOIF,IAFA/ROADS,TEI headers,GILS或RDF)。

DC各次会议发展简表

主要

会议时间地点主持 主要讨论议题及成果

单位

与会代表一致认为有

美国 必要产生一个简单的

DC-1 1995年

俄亥 描述网络上文件类对

3月 俄州OCLG/ 象(DLO)资源的元素

1-3 Dublin NCSA 集,并最终产生了一个

Core 包含十三个元素的元

素集,即The Dublin

Core Set.

会议主要讨论了元数

1996年 据描述模型之间的互

DC-2 4月

英国UKOLN 操作性,及其展开的机

1-3 War-/OCLC 制,即Warwick框架。

日wick Warwick框架和Meta

Content框架成为RDF

框架发展的基础。

会议主要讨论了网络

上的图像资源问题,认

美国 为把已有的十三个DC

1996年俄亥CNI/ 元素进行一定的修改

DC-3 9月

俄州OCLC 后,同样可用来描述图

24-25Dublin像对象,并增加了两个

日Core 元素:Description和

Rights Management,使

元素的个数增加到十

五个.

会议产生了两大派别:

最小主义学派和结构

语言学派.会议正式

1997年澳大NLA/ 定义了三个限定词;语

DC-4 3月

利亚DSTC/ 言,体系和类型(子元

3-5 堪培拉

OCLC 素名);另外,还讨论了

日 把元数据模型和命名

域相联合以及在

HTML2.0中嵌入堪培

拉限定词等问题.

会议讨论了日期,覆盖

范围和关联这三个元

1997年

芬兰

素,使十五个DC元素

DC-5 10月赫尔OCLC/ 的定义讨论最终告一

辛基NIF段落.会后生成了一

个子元素专题组,并使

Z39.50能支持用DC

指定的搜索.

1998年 美国

11月

华盛顿LOC/

DC-6 2-4特区 OCLC

标签:;  ;  ;  ;  ;  ;  

都柏林核心元数据发展简史(下)_元数据论文
下载Doc文档

猜你喜欢