元数据抽象模型与新加坡框架

刘炜上海图书馆

2007数字图书馆建设与应用研讨会 *深圳

主要内容

DC 元数据标准规范体系 DC 元数据抽象模型 DC 元数据新加坡框架：应用纲要的规范

形式

Creator Title Subject

Contributor Date Description

Publisher Type Format

Coverage Rights Relation

Source Language I dentifier

说明： Google 图片搜索对此 slide亦有贡献

DC 元数据标准规范体系

Element | DCMES, DCQ

Element |DCAMDCAP (DCTerms++)

• DC1.0

• DC2.0

DC1.0

Elements 元素 Qualifiers 修饰词

Element Refinements 元素修饰词 ( 子元素 ) Encoding Schemes 编码体系修饰词

Vocabulary Encoding Schemes 词表编码体系 Syntax Encoding Schemes 语法编码体系

参见 :http://dublincore.org/usage/documents/principles/#element

DC 应用纲要 1.0

CWA14855 定义 指南性文档 没有对于元数据编码的任何规定 不支持 DCAM 不支持 Description Set ( 描述集 )

DC 眼中的世界 (DCAM)

任何事物都是资源 资源有类型 任何资源都可以以 URI 标识

任何资源都有属性 属性词即元数据 属性词表即元数据方案 元数据方案可有多种形式：不 / 半 / 规范的 应用纲要是一种正在成型的半 / 规范形式

任何属性都有属性值 属性值有领域和范围 (domain & range) 属性值可以是另一个资源，可以是文字 (literal)

取值的规范控制，即各类 KOS ，也是元数据

DCMI 类型词表 (DCTYPE)

DC 元数据描述的资源对象可能存在的类型： Collection Dataset Event Image

MovingImage StillImage

InteractiveResource PhysicalObject Service Software Text

“ 资源”的唯一必备属性： URI

URI:Uniform Resource Identifier (RFC3986 定义 ) 唯一必备功能：标识资源 ( 无论是物理的还是抽象的 ) ； 包含三部分：

访问资源的命名机制 存放资源的主机名 资源自身的名称，由路径表示

两种类型： URL 如：

http://www.ietf.org/rfc/rfc3986.txt mailto:java-net@java.sun.com news:comp.lang.java

URN 如： urn:isbn:096139210x urn:doi:10.1045/november2007-kaufman

URI 是抽象类，并不规定解析

进一步说明1. 元数据是一种人工语言（消除歧义、明确定义、人机共读）；2. 元数据元素集是描述资源各个方面的属性词表；3. 元数据取值如果规定只能从某些词表中选取，这些词表就属于受控的规

范词表；这属于元素取值的 domain 和 range ；4. 元数据应用纲要是为了领域应用而制订的元数据方案的一种表达形式，

目前正在成为规范的，叫做“ DC 元数据应用纲要”，核心是符合 DC 抽象模型的元数据形式化表述（也就是一种机读形式），通常可以以 RDF形式表达；

5. 应用模型（规定应用领域的各类实体及其相互关系）、著录规则等文档，也可以成为元数据应用纲要的组成部分；

6. 元数据注册系统可以作为元数据元素的命名域管理体系而存在，但命名域并非一定需要注册系统进行管理；

7. 元数据元素词表，包括规定元数据取值的规范词表，都可以看成是一种人工语言，每个术语都应该被赋予唯一的 URI ，都可以通过注册系统进行管理；

8. 元数据形式化的表达必须采用基于 XML 的 RDF或 OWL等的 Schema ，著录工作单当然可以通过完整表达元数据方案各种关系和约束的 schema来自动生成，并进行校验。当然这需要一定的环境和软件工具来实现

Resource has property

DC:CreatorDC:TitleDC:SubjectDC:Date...

X

主语

谓词属性词 属性值

[optional qualifier]

[optional qualifier]

修饰 /限定词

来自 (from) ： Stuart Weibel

Resource has Date "2000-06-13"Revised

ISO8601

Resource has Subject "Languages -- Grammar"LCSH

来自 (from) ： Stuart Weibel

DC 属性元素的“领域和范围 (Domain and Range)”

见： http://dublincore.org/documents/domain-range/index.shtml

Record (encoded as html, XML, or RDF/XML

Description set

Resource Description (URI)Resource Description (URI)Resource Description (URI)

Statement

Statement

Statement

language

(pt-BR)

DCAM 图示 (来自 Andy Powell)

value string

value URIproperty (URI)

syntax encodingscheme

Vocabulary encoding scheme

新加坡框架进一步定义了 DC 应用纲要符合 DC 抽象模型 (DCAM) 的应用纲要

(“DC 应用纲要” ) 包含如下一系列文档： 功能需求说明 ( 必须 desirable) 领域模型 ( 应有 mandatory) 元素集描述 (DSP) ( 应有 mandatory) 应用指南 ( 可选 ) 编码句法指南 ( 可选 )

应用指南

功能需求 领域模型 元素集描述

编码指南与数据格式

社区领域模型 元素词表 DCMI

抽象模型DCMI句法指南

RDF/S RDF

标注 Annotate

建立基础

建立基础

建立基础

使用 使用 建立基础

建立基础

建立基础

建立基础

建立基础

建立基础基础标准

领域标准

DC 应用纲要

新加坡框架图示 (来自 Tom Baker)

描述集纲要 (DSP)

定义了描述集在结构方面的约束 :允许出现怎样的描述允许采用怎样的属性怎样的属性值聚合方式

以 XML 表达 (RDF当然是 XML) 忽略元素的定义 (通过 URI 参考 ) 忽略版本控制 不要求应用指南著录规范等给人读的文档

翻译、修改自 Mikael Nelsson 的演讲稿

参见： http://dublincore.org/architecturewiki/DescriptionSetProfile

当前元数据研究和应用中的问题 人读而非机读 语义的模糊性 模型的完整性 ( 两类模型： FRBR 和 DCAM) 执行的一致性 数据的独立性 基本上无法编码实现（包括数据库系统开发）

我们目前的元数据方案可以说只完成了 MARC 数据格式的定义，还没有 2709格式使其真正机器可读

从这一点来说，目前各类元数据著作、方案中值得推敲的地方还是比较多的

一些建议 建立本地化扩展术语的命名域参考 建立元数据应用纲要 ( 词表 )及编码的登记注册

体系 修订目前的领域应用元数据应用纲要 推进元数据集成开发系统 (IDE)软件和工具的开发

建立数字图书馆标准规范的开放讨论维护机制 “ 机读版”元数据方案的推广、培训

随着元数据应用的开展和普及，一致性问题越来越严重。现在如果不重视，将后患无穷！

问题讨论

元素名是否应该翻译？

dc:creator“Verfasser”标签

“Creator”标签

“创建者”

标签

[Server inGermany]

[Server in CAS]

[DCMI Server]

（上图改编自 Stuart Weibel 有关演示文稿）

• 元素名只是一个机器识别的符号 (Token) 而已• 一个符号 (token) ，多种翻译 (labels)• 如果翻译了，就不是 DC 了 (“盗版 DC“ ？ )

元数据“记录”是怎样的结构？

过去称为记录的，多为现在所称的描述平面化 (MARC 中的记录 ) “虚拟记录”传统结构：数据库记录 - 文件系统 描述 / 描述集

1:1原则是针对描述而言，而非记录 描述 / 描述集可以通过不同的记录形式 /格式来实现

DCAM打散了资源描述，在具体应用中如何实现？

DCAM 是一个抽象模型，不考虑具体实现（如记录的统一、聚类等）；

DCAM提供需求分析、功能设计的思路和方法，应用系统可以采用任何方式实现功能；

目前 URI 是一切Web 资源描述的基础，包括 URL 和 URN 两类。 URN(eg:DOI/ISBN ，甚至各类词表 ) 如何实现全局解析，不是 Web 的事情，是行业应用的事情；

URI 不是完美的资源标识方法，新的方法正在研讨中

编码问题……<creator> <name>John Doe</name> <date> <earliestDate>1589</earlestDate> <latestDate>1670</latestDate>

</date></creator>

主要问题：元数据描述集 / 元数据描述 1:1 Token 的应用： dc.creator, dcterms.date… 元素的扩展： name （是否是 FOAF 的 name?） 嵌套表示是否值得推荐？ 编码体系修饰词的采用 ( 如： W3CDTF)

元数据抽象模型与新加坡框架

谢谢！

欢迎访问 DC 中文网： http://dublincore.cn/