2007数字图书馆建设与应用研讨会*深圳 元数据抽象模型与新加坡框架 刘炜 上海图书馆

主要内容 DC元数据标准规范体系 DC元数据抽象模型 DC元数据新加坡框架：应用纲要的规范形式 纯属介绍，没有原创，但是容易被忽视 本来想涉及编码方案的，由于关于编码的最佳实践非常琐碎，而且目前应用实践还没有很大需求，暂且不讲。以后专文介绍。 文中所涉及的内容，许多为本人理解，一些为尚无定论，欢迎讨论。内容都是别人的，错误都是我的

80%的人对DC元数据的认识：15个元素

说明：Google图片搜索对此slide亦有贡献 DC怪物 15%的人对DC的理解 说明：Google图片搜索对此slide亦有贡献

DC1.0 DC2.0 DC元数据标准规范体系 Element | DCMES, DCQ Element |DCAMDCAP (DCTerms++)

DC1.0 Elements元素 Qualifiers修饰词 Element Refinements元素修饰词(子元素) Encoding Schemes编码体系修饰词 Vocabulary Encoding Schemes词表编码体系 Syntax Encoding Schemes语法编码体系 1Elements 2Qualifiers 2.1Element Refinements 2.2Encoding Schemes 2.2.1vocabulary encoding schemes 2.2.2syntax encoding schemes 参见:http://dublincore.org/usage/documents/principles/#element

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

DC眼中的世界(DCAM) 任何事物都是资源 任何资源都有属性 任何属性都有属性值 属性值有领域和范围(domain & range) 资源有类型 任何资源都可以以URI标识 任何资源都有属性 属性词即元数据 属性词表即元数据方案 元数据方案可有多种形式：不/半/规范的 应用纲要是一种正在成型的半/规范形式 任何属性都有属性值 属性值有领域和范围(domain & range) 属性值可以是另一个资源，可以是文字(literal) 取值的规范控制，即各类KOS，也是元数据 资源是类 属性(词)是类 属性词是资源

DCMI类型词表(DCTYPE) DC元数据描述的资源对象可能存在的类型： Collection Dataset Event Image MovingImage StillImage InteractiveResource PhysicalObject Service Software Text A resource requiring interaction from the user to be understood, executed, or experienced. Examples include forms on Web pages, applets, multimedia learning objects, chat services, or virtual reality environments.

“资源”的唯一必备属性：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是抽象类，并不规定解析

进一步说明 元数据是一种人工语言（消除歧义、明确定义、人机共读）； 元数据元素集是描述资源各个方面的属性词表； 元数据取值如果规定只能从某些词表中选取，这些词表就属于受控的规范词表；这属于元素取值的domain和range； 元数据应用纲要是为了领域应用而制订的元数据方案的一种表达形式，目前正在成为规范的，叫做“DC元数据应用纲要”，核心是符合DC抽象模型的元数据形式化表述（也就是一种机读形式），通常可以以RDF形式表达； 应用模型（规定应用领域的各类实体及其相互关系）、著录规则等文档，也可以成为元数据应用纲要的组成部分； 元数据注册系统可以作为元数据元素的命名域管理体系而存在，但命名域并非一定需要注册系统进行管理； 元数据元素词表，包括规定元数据取值的规范词表，都可以看成是一种人工语言，每个术语都应该被赋予唯一的URI，都可以通过注册系统进行管理； 元数据形式化的表达必须采用基于XML的RDF或OWL等的Schema，著录工作单当然可以通过完整表达元数据方案各种关系和约束的schema来自动生成，并进行校验。当然这需要一定的环境和软件工具来实现

Resource has property X 属性词 属性值 谓词 主语 修饰/限定词 [optional qualifier] DC:Creator DC:Title DC:Subject DC:Date... 主语 Resource has property X 修饰/限定词 [optional qualifier] [optional qualifier] 来自(from)：Stuart Weibel

Resource has Subject "Languages -- Grammar" Resource has Date LCSH Resource has Date "2000-06-13" ISO8601 Revised 来自(from)：Stuart Weibel

DC属性元素的“领域和范围(Domain and Range)” 见：http://dublincore.org/documents/domain-range/index.shtml

DCAM图示(来自Andy Powell) Record (encoded as html, XML, or RDF/XML Description set Resource Description (URI) Resource Description (URI) Resource Description (URI) Statement Statement Vocabulary encoding scheme Statement property (URI) value URI value string syntax encoding scheme language (pt-BR)

新加坡框架进一步定义了DC应用纲要 符合DC抽象模型(DCAM)的应用纲要 (“DC应用纲要”) 包含如下一系列文档： 功能需求说明(必须desirable) 领域模型 (应有mandatory) 元素集描述 (DSP) (应有mandatory) 应用指南 (可选) 编码句法指南(可选) 元数据应用纲要的新定义 最大的不同：DSP: Description Set Profile

新加坡框架图示(来自Tom Baker) 应用指南 DC应用纲要 功能需求 领域模型 元素集 描述 编码指南 与数据格式 社区领域 模型 标注 Annotate 功能需求 领域模型 元素集 描述 编码指南 与数据格式 建立基础 建立基础 建立基础 使用 使用 建立基础 建立基础 社区领域 模型 元素词表 DCMI 抽象模型 DCMI 句法指南 建立基础 建立基础 建立基础 领域标准 RDF/S RDF 建立基础 基础标准

描述集纲要(DSP) 定义了描述集在结构方面的约束: 以XML表达(RDF当然是XML) 忽略元素的定义(通过URI参考) 忽略版本控制 允许出现怎样的描述 允许采用怎样的属性 怎样的属性值聚合方式 以XML表达(RDF当然是XML) 忽略元素的定义(通过URI参考) 忽略版本控制 不要求应用指南著录规范等给人读的文档 形式化描述的实现试验：SHAME项目，自动生成XML/RDF表单，共转换、输入数据。 翻译、修改自Mikael Nelsson的演讲稿

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

当前元数据研究和应用中的问题 人读而非机读 语义的模糊性 模型的完整性(两类模型：FRBR和DCAM) 执行的一致性 数据的独立性 基本上无法编码实现（包括数据库系统开发） 我们目前的元数据方案可以说只完成了MARC数据格式的定义，还没有2709格式使其真正机器可读 从这一点来说，目前各类元数据著作、方案中值得推敲的地方还是比较多的

一些建议 随着元数据应用的开展和普及，一致性问题越来越严重。现在如果不重视，将后患无穷！ 建立本地化扩展术语的命名域参考 建立元数据应用纲要(词表)及编码的登记注册体系 修订目前的领域应用元数据应用纲要 推进元数据集成开发系统(IDE)软件和工具的开发 建立数字图书馆标准规范的开放讨论维护机制 “机读版”元数据方案的推广、培训 随着元数据应用的开展和普及，一致性问题越来越严重。现在如果不重视，将后患无穷！ 科技部成果大多可以看成是基于领域应用的应用纲要，其扩展的术语（包括元素、元素修饰词、编码体系修饰词）及其定义、解释，都应该建立命名域参考，以便复用和参考引用。 理想的方式是通过登记注册体系全面地实现元数据术语管理，除了命名域管理之外，还提供属性词表、取值词表（编码体系）的管理，包括查询、版本管理、编码模式管理等功能。 针对已有的具体应用领域，建立基于新加坡框架的机器可读元数据应用纲要（即形式化的元数据方案），为此现有的元数据方案需要进行审查和修订。 机读版的应用纲要通常是RDF/RDFS形式，使这类应用刚要发挥作用，必须要固化到一定的软件工具或应用平台上去。这一步可以由企业和图书馆界一起进行。 建立开放讨论维护机制，但不一定是”权威组织”，而是建立元数据开放共享的平台，营建社区，大家一起来讨论。

问题讨论

元素名是否应该翻译？ 元素名只是一个机器识别的符号(Token)而已 一个符号(token)，多种翻译(labels) 如果翻译了，就不是DC了 (“盗版DC“？) dc:creator “Verfasser” 标签 “Creator” 标签 [Server in Germany] [DCMI Server] “创建者” 标签 [Server in CAS] （上图改编自Stuart Weibel有关演示文稿）

元数据“记录”是怎样的结构？ 过去称为记录的，多为现在所称的描述 平面化(MARC中的记录) “虚拟记录” 传统结构：数据库记录-文件系统 描述/描述集 1:1原则是针对描述而言，而非记录 描述/描述集可以通过不同的记录形式/格式来实现

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/