gis
gis
管理员
管理员
  • 注册日期2003-07-16
  • 发帖数15945
  • QQ554730525
  • 铜币25337枚
  • 威望15352点
  • 贡献值0点
  • 银元0个
  • GIS帝国居民
  • 帝国沙发管家
  • GIS帝国明星
  • GIS帝国铁杆
阅读:2501回复:1

都柏林核心(Dublin Core)元数据发展简史

楼主#
更多 发布于:2003-11-13 08:48
随着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)。

本文是一篇关于DC的产生及其发展历史的简要概括,文中对各次会议都依次作了介绍。相信在读完本篇后,能使你对DC这一目前在国外数字图书馆及网络资源描述方面有重要意义的元数据集有一个基本的、粗略的了解。

 

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)项目专门对现有的多种元数据类型进行了分析和比较,并把它们分为了三个级别:

 

  一 级
 二 级
 三 级
 
记录
 简单格式
 结构化格式
 复杂格式
 
特征
 私有
 成为逐渐形成的标准
 已成为国际标准
 
  全文索引
 结构化字段
 详细标识
 
记录格式
 Lycos
 Dublin Core
 ICPSR
 
  Altavista
 IAFA templates
 CIMI
 
  Yahoo etc
 RFC 1807
 EAD
 
    SOIF
 TEI
 
    LDIF
 MARC
 

 

级别一包括的是相对来说未经结构化的元数据,特别是从资源中自动抽取并索引的。这些数据一般是由搜索引擎产生的。如果用户用它们来查询一个已知条目,它们还比较有用。但用户必须对查出的大量资源进行筛选,并且还可能会错过一些潜在相关的资源,因为它们没有使用适当的术语进行索引。

级别二中包括的元数据允许使用者不用对资源进行检索或联系,就能对资源的潜在用途或重要性进行判断。这些数据已被结构化并支持字段查询。更重要的是这些简单的数据记录能让非专业用户自己来创造,而不需要什么特定学科的知识。描述一般是手工进行的,或是用自动抽取的描述来帮助手工编制。

级别三中复杂的描述格式能用于定位(location)和发现,还可用于对对象的证明(document)和收藏(collection),它们一般用于研究与学术活动,需要专业知识来创造和维护,并迎合专家们在特定领域的要求。

在这样的一个背景中,可以发现在各个级别间有一种跨越的趋势。由作者或站点制作的元数据在很多方面将会变得越来越重要。[DESIRE]

在上面这个图表中我们可以看到DC被置于第二级别中,它所提供的记录是为了调和级别一和级别三这两种极端,来提供一种简单结构的记录。DC并不是要替代其它的资源描述类型,而是对它们进行补充。DC能通过扩展或通过对更复杂的记录的链接来增强其功能,并被对应到其它更复杂的记录中去。

 

DC-1会议集中讨论了文件类对象(DLO)的信息检索所需要的元数据元素。因为DLO至今仍是因特网上的资源主流,并且适用于DLO的任何处理方法都能被扩展到其它类型的资源。

由于因特网上所包含的信息要比以往的专业摘要人员、索引人员和编目者所用的方法及系统管理的信息多得多,因此一个可行的获得电子资源的元数据的方法是:让作者和信息提供者无须经过对现有标准的特别培训,就能自己来描述资源。

尽管都柏林元数据研讨会的目的是开发一个简单的元数据元素集,但这些元素的定义仍使其能与更复杂的控制系统,如MARC进行桥接。这些矛盾从两个方面得到了解决:一方面是创造一个不要对用户进行培训就能容易理解的元数据元素集,和一个能满足特殊用户的更精确的描述要求的修正方案。另一方面,是提供一种能扩展核心元素集的机制,来描述除文件类对象以外的内容。

美国会图书馆的 Rebecca Guenther指出DC具有四个优点:(1)DC将鼓励作者和出版者以自动资源发现工具能收集的形式来提供元数据。(2)它将鼓励包含有元数据元素模块的网络出版工具的创造,从而进一步简化元数据记录的创造工作。(3)如果有可能的话DC生成的记录能作为更详细的编目记录的基础。(4)如果DC成为标准,那么元数据记录就能被各用户团体所了解。

DC具备如下一些特性:内在性(intrinsicality)、可扩展性(extensibility)、独立句法结构(syntax independence)、可选择性(optionality)、可重复性(repeatability)及可修改性(modifiability)。

元数据专题组的讨论透露了指导元素集进一步发展的原则。伴随着这些原则将出现这些可能:核心元素集越小越好,且能被大多数用户所理解,元素集能灵活的描述广泛的主题区域内的资源。[DC-1]

 

DC-2

第二届元数据研讨会是由UKOLN和OCLC组织的,它于1996年4月1-3日在英国的Warwick召开。它旨在扩大第一届OCLC/NCSA元数据研讨会的影响。第一届会议主要围绕一个简单的资源描述记录的产生展开了讨论,即广为人知的都柏林核心元素集DC,并最终达成了共识。它可作为一个统一各种网络资源描述模型的基础。

在Warwick召开的会议上,出席的人员有计算机专家,文本标示人员和图书馆专家。还有美国数字图书馆倡议项目的代表,英国JISC电子图书馆项目,以及欧洲和澳大利亚图书馆方面的代表。另外还有如MARC这样的标准制定团体及一些公司的代表。

 

第二届研讨会的目的主要是“确认能满足两个目的的执行策略:

促进各学科和语言间的语意协作能力;

定义一种可扩展的机制来支持对其它描述模型的更详细的描述和联接。”

但研讨会的重点很快就转移到了可扩展性问题上,其它问题基本未被触及。

主题组还讨论了句法(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十五个元素的中文定义简介,可通过上海图书馆网站上的http://www.istis.sh.cn/istis/dlib/report/metadata.html 页面获得。

把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中的坎帕拉限定词应用


喜欢0 评分0
gis
gis
管理员
管理员
  • 注册日期2003-07-16
  • 发帖数15945
  • QQ554730525
  • 铜币25337枚
  • 威望15352点
  • 贡献值0点
  • 银元0个
  • GIS帝国居民
  • 帝国沙发管家
  • GIS帝国明星
  • GIS帝国铁杆
1楼#
发布于:2003-11-13 08:48
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-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)

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

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

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

 

未限定的DC元素的语义讨论在赫尔辛基完成了(Finnish Finish)。 Finnish Finish将成为第一个DC的正式标准基础,并为它的广泛应用提供支持。

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

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

 



应用限定的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 for Commnets)文件中被正式确认。RFC的文件都是正式的标准并具有一定的资历。最后RFC2413文件正式承认了Dublin Core在网络信息描述中的地位。[DC-5]

 

DC-6

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

 

现在国际上有关Dublin Core 的研究已进行得如火如荼,越来越多的项目都采用了DC,有关各个DC执行项目的情况可从http://purl.oclc.org/docs/core/projects网页上获得。在我们国内,中国国家实验型数字式图书馆项目所采用的最小元数据集合就是Dublin Core。相信随着这一项目的实施,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月1-3日
 美国俄亥俄州的Dublin Core
 OCLC/NCSA
 与会代表一致认为有必要产生一个简单的描述网络上文件类对象(DLO)资源的元素集,并最终产生了一个包含十三各元素的元素集,即The Dublin Core Set。
 
DC-2
 1996年4月1-3日
 英国,Warwick
 UKOLN/OCLC
 会议主要讨论了元数据描述模型之间的互操作性,及其展开的机制,即Warwick框架。Warwick框架和 Meta Content框架成为RDF框架发展的基础。
 
DC-3
 1996年9月24-25日
 美国俄亥俄州的Dublin Core
 CNI/OCLC
 会议主要讨论了网络上的图象资源问题,认为把已有的十三个DC元素进行一定的修改后,同样可用来描述图象对象,并增加了两个元素:Description和 Rights Management,使元素的个数增加到十五个。
 
DC-4
 1997年3月3-5日
 澳大利亚首都堪培拉
 NLA/DSTC/OCLC
 会议产生了两大派别:最小主义学派和结构语言学派。会议正式定义了三个限定词:语言,体系和类型(子元素名);另外,还讨论了把元数据模型和命名域相联合以及在HTML2.0中嵌入坎帕拉限定词等问题。
 
DC-5
 1997年10月
 芬兰首都赫尔辛基
 OCLC/NLF
 会议讨论了日期,覆盖范围和关联这三个元素,使十五DC元素的定义讨论最终告一段落。会后生成了一个子元素专题组,并使Z39.5O能支持用DC指定的搜索。
 
DC-6
 1998年11月2-4日
 美国华盛顿特区
 LOC/OCLC
举报 回复(0) 喜欢(0)     评分
游客

返回顶部