元数据抽象模型与编码方案.ppt

元数据抽象模型与新加坡框架 刘炜上海图书馆 主要内容 DC元数据标准规范体系 DC元数据抽象模型 DC元数据新加坡框架：应用纲要的规范形式 DC元数据标准规范体系 DC1.0 Elements元素 Qualifiers修饰词 Element Refinements元素修饰词(子元素) Encoding Schemes编码体系修饰词 Vocabulary Encoding Schemes词表编码体系 Syntax Encoding Schemes语法编码体系 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 如： /rfc/rfc3986.txt mailto:java-net@ news:comp.lang.java URN 如： urn:isbn:096139210x urn:doi:10.1045/november2007-kaufman URI是抽象类，并不规定解析 进一步说明 元数据是一种人工语言（消除歧义、明确定义、人机共读）； 元数据元素集是描述资源各个方面的属性词表； 元数据取值如果规定只能从某些词表中选取，这些词表就属于受控的规范词表；这属于元素取值的domain和range； 元数据应用纲要是为了领域应用而制订的元数据方案的一种表达形式，目前正在成为规范的，叫做“DC元数据应用纲要”，核心是符合DC抽象模型的元数据形式化表述（也就是一种机读形式），通常可以以RDF形式表达； 应用模型（规定应用领域的各类实体及其相互关系）、著录规则等文档，也可以成为元数据应用纲要的组成部分； 元数据注册系统可以作为元数据元素的命名域管理体系而存在，但命名域并非一定需要注册系统进行管理； 元数据元素词表，包括规定元数据取值的规范词表，都可以看成是一种人工语言，每个术语都应该被赋予唯一的URI，都可以通过注册系统进行管理； 元数据形式化的表达必须采用基于XML的RDF或OWL等的Schema，著录工作单当然可以通过完整表达元数据方案各种关系和约束的schema来自动生成，并进行校验。当然这需要一定的环境和软件工具来实现 DCAM图示(来自Andy Powell) 新加坡框架进一步定义了DC应用纲要 符合DC抽象模型(DCAM)的应用纲要 (“DC应用纲要”) 包含如下一系列文档： 功能需求说明(必须desirable) 领域模型 (应有mandatory) 元素集描述 (DSP) (应有mandatory) 应用指南 (可选) 编码句法指南(可选) 描述集纲要(DSP) 定义了描述集在结构方面的约束: 允许出现怎样的描述 允许采用怎样的属性 怎样的属性值聚合方式 以XML表达(RDF当然是XML) 忽略元素的定义(通过URI参考) 忽略版本控制 不要求应用指南著录规范等给人读的文档 当前元数据研究和应用中的问题 人读而非机读 语义的模糊性 模型的完整性(两类模型：FRBR和DCAM) 执行的一致性 数据的独立性 基本上无法编码实现（包括数据库系统开发） 我们目前的元数据方案可以说只完成了MARC数据格式的定义，还没有2709格式使其真正机器可读 从这一点来说，目前各类元数据著作、方案中值得推敲的地方还是比较多的 一些建议 建立本地化扩展术语的命名域参考 建立元数据应用纲要(词表)及编码的登记注册体系 修订目前的领域应用元数据应用纲要 推进元数据集成开发系统(IDE)软件和工具的开发 建立数字图书馆标准规范的开放讨论维护机制 “机读版”元数据方案的推广、培训 随着元数据应用的开