元数据抽象模型与新加坡框架
刘炜
上海图书馆
2007数字图书馆建设与应用研讨会*深圳
主要内容
¡ DC元数据
规范体系
¡ DC元数据抽象模型
¡ DC元数据新加坡框架:应用纲要的规范
形式
Creator Title Subject
Contributor Date Description
Publisher Type Format
Coverage Rights Relation
Source Language Identifier
说明:Google图
片搜索对此slide亦
有贡献
DC元数据标准规范体系
Element | DCMES, DCQ
Element |DCAMàDCAP (DCTerms++)
• DC1.0
• DC2.0
DC1.0
¡ Elements元素
¡ Qualifiers修饰词
l Element Refinements元素修饰词(子元素)
l Encoding Schemes编码体系修饰词
¡ Vocabulary Encoding Schemes词表编码体系
¡ Syntax Encoding Schemes语法编码体系
参见:http://dublincore.org/usage/documents/principles/#element
DC应用纲要1.0
¡ CWA14855定义
¡ 指南性文档
¡ 没有对于元数据编码的任何规定
¡ 不支持DCAM
¡ 不支持Description Set (描述集)
DC眼中的世界(DCAM)
¡ 任何事物都是资源
l 资源有类型
l 任何资源都可以以URI标识
¡ 任何资源都有属性
l 属性词即元数据
l 属性词表即元数据
l 元数据方案可有多种形式:不/半/规范的
l 应用纲要是一种正在成型的半/规范形式
¡ 任何属性都有属性值
¡ 属性值有领域和范围(domain & range)
¡ 属性值可以是另一个资源,可以是文字(literal)
l 取值的规范控制,即各类KOS,也是元数据
DCMI类型词表(DCTYPE)
DC元数据描述的资源对象可能存在的类型:
¡ Collection
¡ Dataset
¡ Event
¡ Image
l MovingImage
l StillImage
¡ InteractiveResource
¡ PhysicalObject
¡ Service
¡ Software
¡ Text
“资源”的唯一必备属性:URI
¡ URI:Uniform Resource Identifier (RFC3986定义)
¡ 唯一必备功能:标识资源(无论是物理的还是抽象的);
¡ 包含三部分:
l 访问资源的命名机制
l 存放资源的主机名
l 资源自身的名称,由路径表示
¡ 两种类型:
l URL 如:
¡ http://www.ietf.org/rfc/rfc3986.txt
¡ mailto:java-net@java.sun.com
¡ news:comp.lang.java
l 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:Creator
DC:Title
DC:Subject
DC: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)
StatementStatementStatement
language
(pt-BR)
DCAM图示(来自Andy Powell)
value string
value URIproperty (URI)
syntax encoding
scheme
Vocabulary
encoding scheme
新加坡框架进一步定义了DC应用纲要
符合DC抽象模型(DCAM)的应用纲要 (“DC
应用纲要”) 包含如下一系列文档:
¡ 功能需求说明(必须desirable)
¡ 领域模型 (应有mandatory)
¡ 元素集描述 (DSP) (应有mandatory)
¡ 应用指南 (可选)
¡ 编码句法指南(可选)
应用指南
功能需求 领域模型
元素集
描述
编码指南
与数据格式
社区领域
模型
元素词表
DCMI
抽象模型
DCMI
句法指南
RDF/S RDF
标注 Annotate
建立
基础
建立
基础
建立
基础
使 用 使 用
建立
基础
建立
基础
建立
基础
建立
基础
建立
基础
建立
基础基础标准
领域标准
DC应用纲要
新加坡框架图示(来自Tom Baker)
描述集纲要(DSP)
¡ 定义了描述集在结构方面的约束:
l 允许出现怎样的描述
l 允许采用怎样的属性
l 怎样的属性值聚合方式
¡ 以XML表达(RDF当然是XML)
¡ 忽略元素的定义(通过URI参考)
¡ 忽略版本控制
¡ 不要求应用指南著录规范等给人读的文档
翻译、修改自Mikael Nelsson的演讲稿
参见:http://dublincore.org/architecturewiki/DescriptionSetProfile
当前元数据研究和应用中的问
¡ 人读而非机读
¡ 语义的模糊性
¡ 模型的完整性(两类模型:FRBR和DCAM)
¡ 执行的一致性
¡ 数据的独立性
¡ 基本上无法编码实现(包括数据库系统开发)
¡ 我们目前的元数据方案可以说只完成了MARC数据格式的
定义,还没有2709格式使其真正机器可读
¡ 从这一点来说,目前各类元数据著作、方案中值得推敲的
地方还是比较多的
一些建议
¡ 建立本地化扩展术语的命名域参考
¡ 建立元数据应用纲要(词表)及编码的登记注册体
系
¡ 修订目前的领域应用元数据应用纲要
¡ 推进元数据集成开发系统(IDE)软件和工具的开
发
¡ 建立数字图书馆标准规范的开放讨论维护机制
¡ “机读版”元数据方案的推广、培训
随着元数据应用的开展和普及,一致性
问题越来越严重。现在如果不重视,
将后患无穷!
问题讨论
元素名是否应该翻译?
dc:creator“Verfasser”
标签
“Creator”
标签
“创建者”
标签
[Server in
Germany]
[Server
in CAS]
[DCMI Server]
(上图改编自Stuart Weibel有关演示文稿)
•元素名只是一个机器识别的符号(Token)而已
•一个符号(token),多种翻译(labels)
•如果翻译了,就不是DC了 (“盗版DC“?)
元数据“记录”是怎样的结构?
¡ 过去称为记录的,多为现在所称的描述
l 平面化(MARC中的记录)
l “虚拟记录”
l 传统结构:数据库记录-文件系统
l 描述/描述集
¡ 1:1原则是针对描述而言,而非记录
¡描述/描述集可以通过不同的记录形式/格式来实
现
DCAM打散了资源描述,在具体应用中如何实现?
¡ DCAM是一个抽象模型,不考虑具体实现(如记
录的统一、聚类等);
¡ DCAM提供需求分析、功能
的思路和
,
应用系统可以采用任何方式实现功能;
¡ 目前URI是一切Web资源描述的基础,包括URL
和URN两类。URN(eg:DOI/ISBN,甚至各类
词表)如何实现全局解析,不是Web的事情,是
行业应用的事情;
¡ URI不是完美的资源标识方法,新的方法正在研
讨中
编码问题
……
John Doe
1589
1670
¡ 主要问题:元数据描述集/元数据描述1:1
¡ Token的应用:dc.creator, dcterms.date…
¡ 元素的扩展:name(是否是FOAF的name?)
¡ 嵌套表示是否值得推荐?
¡ 编码体系修饰词的采用(如:W3CDTF)
元数据抽象模型与新加坡框架
谢谢!