DC-Lib应用纲要错误一例

马上要召开DC-2008了,DC的邮件列表里又热闹起来。今天的一个帖子说到DC-Lib应用纲要的问题,让我想到最近有人建议尽快将DC修饰词和领域应用一并推向国标。愿望很好,但其实国内对DC元数据的应用还没有形成一种讨论的氛围,许多人都回避讨论,只想交给一些“伪精英们”(也算包括偶吧)制定出来执行就完了,其实这样是无法形成对一些问题的基本理解的,即便推出一个“正确”的国标,也恐怕会因为理解的不同而无法执行,何况对于我们来说做到“正确”是何其困难!前一阵与平台江和谢涛君的争论就很好,“我国数图标准规范研究”项目组内部不多的争论也很好,只是太少了。问题不摆到台面上公开讨论,就为以后大家阳奉阴违埋下伏笔,这是对标准化事业最大的伤害。

问题是这样的:在DC图书馆应用纲要中对于“格式(Format)”的修饰词“媒体(medium)”有一段说明:

Used to specify the medium of the physical carrier of a resource. Format without an element refinement qualifier should be used to specify the electronic format of the resource, using the encoding scheme IMT. Format should be repeated if both are applicable (e.g. a PDF file on CD).
用来特指资源物理载体的媒介类型。“格式”如果不带修饰词,则应该采用IMT(即MIME的格式词——keven注)的编码体系修饰词作为取值,特指资源的电子形式。如果即有电子格式又有物理类型(例如放置于CD上的PDF文件),则应该重复著录。

这段说明完全违反了DCAM(DC元数据抽象模型)所规定的1:1原则,因此是完全错误、应该被修正的。可惜DCMI许多文档的修订工作根本就跟不上。

Andy Powell对这个问题的回答很有意思:

Firstly, dc:format is a total mess. (I guess you knew that!)
Secondly, I think the library AP gets it wrong anyway
…….
Sigh… disclaimer, I chaired the original dc:format working group and hence share some/much of the blame for the mess – but I think it was a mess way before then anyway :-(

当然,Andy也给出了这个问题的解释:

dcterms:medium只能用于描述资源的物理形态(格式),这在抽象模型的domain-range中说得很清楚了。因此dcterms:IMT不能用于修饰dcterms:medium,只能修饰dc:format或dcterms:format。

据此,就不存在重复元素/子元素问题了(因为描述电子格式和物理格式的元素/子元素是不同的)。

, , ,

Powered by ScribeFire.

Popularity: 51% [?]

Tags: DCAP, dublincore, 元数据, 应用纲要

Related posts

“新加坡框架(Singapore Framework)”

沃维克框架、堪培拉限定、芬兰终结……。DC元数据自诞生以来,留下许多里程碑式的成果,如今这些成果中又多了一个:新加坡框架(Singapore Framework)。

新加坡框架是指元数据应用纲要的一种规范形式。虽然应用纲要曾经是欧洲标准CWA14855,但那毕竟只是一个非常笼统、给人作参考的“指南”。DCMI认识到DC的应用一直无法大规模开展,与编码方面的规范一直不统一很有关系,编码的无标准可循造成元数据标准有等于无,各类应用的互操作还是无法进行。然而编码规范的统一是一件不可能的任务,在XML大行其道的今天,任何符合XML模式规范的DC编码,你都不能说它不规范,你也不可能让大家都采用一种XML的DC编码模式。同时专注于语义一致性描述的DCMI怎么可能推荐一种编码而排斥另一种呢?再说现在有RDF/OWL/N3等编码方式(甚至采用关系型数据库来描述和编码),将来还会出来种种新的方式,如何能预料得到呢?所以对于编码的标准化,必须依赖于一种编码模型的标准化。这就是近年来DCMI花大力气研究并反复讨论的“DC元数据抽象模型(DCAM)”。只有独立于语言的编码模型标准化了,才能建立一种标准的形式化编码规范,不论形式化语言用的是什么。

而领域应用中符合DC抽象模型的元数据的形式化方案的整体,就叫做DC元数据应用纲要(DC Metadata Application Profile)。 我们的“专门元数据方案”实际上都可以认为属于领域应用的“应用纲要”。

具体说来,新加坡框架指符合DC元数据抽象模型的元数据应用纲要,应该包含以下几个部分:

  • 功能需求说明(需要desirable)
  • 领域模型 (必需mandatory)
  • 元素集描述 (DSP: Description Set Prifile) (必需mandatory)
  • 应用指南 (可选)
  • 编码句法指南(可选)

 

对于每个部分是否必需Mandatory、需要Desirable还是可选Option,目前的意见还不统一,例如很多图书馆员认为功能需求说明应该是必需的,但是对于形式化的应用纲要,功能需求说明只是给人读的,不像领域模型(可用UML形式化)和元素集合描述等(DSP,用Schema等形式化),无法翻译成机器语言,对于机器来说并非必需。

为进一步说明应用纲要各个部分的关系,这里还有一个框架的图示(版权属于DCMI,本人拥有翻译版权,引用敬请声明),值得好好推敲和学习:

2004年本人在一篇论文中将数字图书馆的元数据描述方案定义为“语义结构(Semantic Architecture)”,并认为有如下几个部分组成:

  • Resource Analysis and Definition
  • Metadata Set Definition (Core and Extended)
  • Encoding and Mapping Rules
  • Guidelines and Best Practices
  • Metadata Registry, Ontologies and Authority Files

与这个“新加坡框架”颇有一些异曲同工呢!

Popularity: 69% [?]

Tags: DC, 会议, 元数据, 元数据, 应用纲要, 新加坡框架, 语义技术

Related posts

DC资源集合描述元数据应用纲要(DC CD AP)进展


Pete Johnston 对于 DC-2005 的总结给我们带来了DC CD AP工作组的最新信息,这些情况都反映在 Pete的ppt报告 中了:

DC CD AP过往一年最显著的进展可能要算是DC CD AP草案的推出,在DC-2005应用委员会的全体会议上”非正式”地讨论了这个草案,除了形式上的修改建议之外,对于存在的几个问题中的一个比较大的问题提出了指导性意见。这个问题是:

在资源集合描述时,如果需要同时用到元素及其元素修饰词,例如dc:relation/dcterms:isReferencedBy;dc:description/dcterms:abstract(dc:rights也会碰到),这两类term修饰的内容会发生矛盾。例如一个资源集合的dc:relation的值是另一个资源集合,而这个资源集合isReferencedBy另一本书;dc:description的值是这个资源集合的一般性描述而dcterms:abstract是其某个单元的摘要。应用委员会建议在这种情况下不能够复用dc:relation或dc:description(或dc:rights)而必须专门为资源集合描述寻找新的元素。

另一些正在讨论、尚未定论的问题(虽然在草案中已经有推荐的规定)是:

1、属性值作为字串还是作为引用(use a (value) URI or a (value) string)?编码体系syntaxencoding scheme/富结构rich representation如何用?相关描述(relateddescriptions)应该允许,但是DC CD AP应该保持术语无关。

2、 资源集合媒体类型(格式)的描述。功能需求提出必须能够描述资源集合中是否有提问所需的媒体格式,于是问题就变得很复杂。

3、 开放的时间段。对于资源集合来说,其内容的时间跨度常常是不可确定的。W3CDTF不支持时间范围的表述,ISO8601支持时间范围,但是不支持一头开放的时间范围,例如1949-?。这个问题需要DC Date WG工作组解决。

4、 资源集合的位置location和服务services分离是否有必要?如何分离?是否isLocatedAt/ isAccessedVia两个修饰词都需要?

DC定义的相关概念如下:

• Collection

- An aggregation of one or more items

• Location

- Aplace where a collection is held (Michael Heaney, Analytical Model)

• Service

-Asystem that provides one or more functions of value to the end-user.Examplesinclude: a photocopying service, a banking service, anauthentication service,interlibrary loans, a Z39.50 or Web server (DCMIType Vocabulary)

- Provided physically or digitally

- User may be human, organisation orsoftware application.

• (DCCD AP) Service

- A system that provides access to theItems within the Collection

来年的工作计划就围绕这些问题进行讨论、提出解决方案,并修订DC CD AP。

序号

工作内容

开始日期

结束日期

1

Revise in light of Usage Board review

2005-09

2005-11

2

Resolve item media-type issue

2005-09

2005-11

3

Finalise isLocatedIn/isAccessedVia properties

2005-11

2006-02

4

Work with DC Date WG on date range format

2005-09

2006-03?

5

Update DCAP

2006-01

2006-04

6

Syntax (based on work by DC Arch WG)

2006-05?

2006-09

7

Crosswalks

2006-05

2006-09

8

Usage Guidelines

2006-05

2006-09

9

Usage Board Review

2006-10

2006-10

DC-2005上资源集合工作组还交流了三篇报告:

来自University of Illinois at Urbana-Champaign的Sarah Shreeves 和Muriel Foulonneau通过网络视频会议形式报告了他们在 几个项目中使用资源集合描述 的情况。

英国博物馆、图书馆、档案馆联合委员会的Kate Fernie介绍了他们承担的 文化遗产资源集合项目 的情况。

大英图书馆的Bill Oldroyd简短地介绍了TEL (The European Library:欧洲图书馆)项目中采用资源集合描述的情况。

DC CD AP草案精简版(2005-8-25)见:
http://www.ukoln.ac.uk/metadata/dcmi/collection-ap-summary/2005-08-25/

草案完整版(2005-8-25)见:
http://www.ukoln.ac.uk/metadata/dcmi/collection-application-profile/




Trackback: http://tb.donews.net/TrackBack.aspx?PostId=623606



Popularity: 45% [?]

Tags: DC, 元数据, 应用纲要, 资源集合, 资源集合元数据, 进展

Related posts