数图研究笔记 » DC Metadata

DC-2011 征文通告

keven — Mon, 31 Jan 2011 00:24:04 +0000

都柏林核心元数据应用国际会议

元数据协同：超越语言进行描述

原文参见：http://dcevents.dublincore.org/index.php/IntConf/dc-2011/schedConf/cfp

本届都柏林核心元数据年会将于2011年9月21日-23日在荷兰海牙召开。

“当今的网络环境下, 元数据正日益成为大规模分布式资源管理的核心工具。近年来,由于跨领域合作交流的驱使,原先相对孤立的元数据社区之间的联系日益密切。但元数据标准尚无法满足各类机构社团间的互操作性需求。元数据协同（Metadata Harmonization）被定义为支持多个元数据规范进行组合的互操作问题，它已成为未来网络资源元数据应用的核心问题.”［1］理解元数据应用纲要的关键在于元数据协同，虽然对于这一点人们有所了解，但是如何设计描述语言却依旧挑战巨大。DC-2011将基于不同元数据方案的交融交汇，重点探讨描述语言设计的理论和实践问题，进行探讨不同的元数据方案之间的相互融合需要解决语言的问题。

截稿及重要时间安排:

投稿截止:2011年4月16日
录用通知:2011年6月18日
定稿提交:2011年7月23日

大会除上述主题外，也欢迎任何其它元数据主题的论文、报告和海报等形式的投稿，如：

元数据制定原则、指南和最佳实践
元数据质量（方法、工具和实践）
概念模型和框架(例如，RDF，DCAM，OAIS)
应用纲要
元数据生成（方法、工具和实践）
跨领域、语言、时间、结构和规模的元数据互操作
跨领域的元数据应用（例如记录留存、永久保存、保管(curation)、机构库、出版）
领域元数据 (例如，企业、文化记忆机构、教育、政府及科研领域）
作为语义网词汇的书目标准（例如，RDA、FRBR、主题词表）
可获得性元数据
科学数据、e-Science和网格应用方面的元数据
社会化标注和元数据构建中的用户参与
使用情况数据（paradata/attention元数据）
知识组织系统(例如：本体、分类法、规范档、大众分类法和叙词表）和SKOS(简单知识组织系统)
本体的设计与开发
元数据与本体的整合
搜索引擎和元数据
关联数据和语义网（元数据及应用）
词汇表注册及注册服务

投稿

所有提交的论文、报告、挂图摘要，和社团工作组、分会场会议必须经过DCMI的同行评议系统（链接在页面底部）。
作者需进入同行评议系统进行注册，在“作者信息”的链接下有相关提交流程的介绍。
.所有的投稿必须用英文撰写。
所有投稿都将由国际性的学术委员会进行专家评审。

出版

经审核通过的论文、项目报告和挂图摘要将在此次会议的官方文集上发表，见http://dcpapers.dublincore.org/ojs/pubs。
分会场会议和社团工作组的文摘将在在线会会议议程上发表
论文、研究报告和挂图摘要必须符合DCMI同行评议系统的格式模板要求。
若无特殊安排，被录用的论文、项目报告和挂图应该至少由其中一位作者在海牙会议上宣读。
为了稿件能够顺利接收与出版，所有的投稿者需提供自己的基本资料，包括目前的专业职务和联系方式等。

稿件的种类

论文（8-10 页）论文既可以详细描述创新性的工作，也可以对前述的一些领域性重要进展或者最佳实践进行介绍评议。

论文评判标准如下：

实现方法的创新性
所做贡献的质量
呈现结果的重要性
表达的明确性

项目报告 （4-5 页）项目报告应该简明扼要地介绍一个特定的模型、应用或者活动。项目报告的评判标准如下：

技术描述的精确性和完整性
对其他潜在用户技术指导的可用性
表达的明确性

挂图 (1-2页) 挂图是关于正在进行中的项目或课题研究的展示，或者已完成项目、课题研究的最新结果的展示。挂图建议应当包括一个长为一到两页的摘要。

挂图的评判标准如下：

精确陈述研究项目的目标和里程碑事件
研究课题或者项目的重要性
陈述主要的难点和进一步的研究
陈述结果和取得的主要成果
表达的明确性

会议现场将会安排一个或多个分会场来展示和讨论这些挂图。在会议网站上将会有关于如何准备挂图展示的指导和说明。除非另有安排，已录用的挂图必须至少由其中一位作者在海牙会议上宣读。根据前期安排，挂图的摘要可能被收入在此次会议的论文集中，并通过4-10分钟的视频进行展示，同时根据提交挂图摘要的URL地址将该视频上传到YouTube网站。

分会场会议 & DCMI社团工作组会议 分会场会议和社团工作组会议的提案应控制在800-1200字内，并含35-50字的用于宣传会议的摘要。会议提案必须明确一下内容：

会议召集人
假如可能，请给出参与者的类型
会议：
- 目的
- 议程
- 活动 (包括任何技术要求)
- 周密而完善的会议日程安排（包括会后总结报告）
- 工作小组会议的提案必须明确具体的DCMI社团（请参见http://www.dublincore.org/groups/#communities）

分会场召集人在会议申请审核通过后需就会议的完善、日程安排和会议的召开与会议主席密切合作。工作组主席经与会议委员会磋商，将会审查分会场会议的提案。工作组主席与DCMI相关社团的主席或联席主席进行磋商后，可以审核社团工作组的提案。会议提案的评估标准如下：

内容的质量和组织结构
选择该格式的理由
调动互动和参与的方法的证据
参与的包容性和多样性
要有吸引一般参会者的可能性，对于工作组会议，则还要吸引社团的兴趣。(包括除会场以外任何必需的技术如Skype)

[1] Nilsson, Mikael. (2010). 元数据标准化从互操作到统一：为元数据的统一设计一个可发展的框架.论文.瑞典皇家理工学院计算机科学和通信专业。斯德哥尔摩，瑞典。http://kmr.nada.kth.se/papers/SemanticWeb/FromInteropToHarm-MikaelsThesis.pdf

作者指南 所有经审核通过后的论文、项目报告和挂图都将收录到DC-2010会议论文集。根据提交文档的类别确定适当的模板格式：

为了确保可读性和文面的一致性，作者应该使用模板来规范投稿格式。

每个类别稿件的最大长度和评判标准都罗列在http://dcevents.dublincore.org/index.php/IntConf/dc-2011/schedConf/cfp的论文要求中。

DCMI坚持以盲审方式进行同行评审，这样作者不知道评审者的方式。但不采用双盲审的方式，因此，评审者可以知道作者的身份。

投稿可以点击下列链接：

投稿流程第一步……

(本中文文档由上海图书馆张晓雯、徐奕宁和王晓樱翻译，张春景、Keven审校，欢迎批评指正。)

讲座预告：关于元数据的最新进展

keven — Wed, 21 Oct 2009 14:50:05 +0000

Update：讲座时间：10月30日上午9：30-11：30。地点：上海图书馆系统网络中心3508会议室。

感谢王松林老师，让我就元数据的最新发展和对语义互操作的理解，给他的研究生介绍一下。我最近将花些时间，系统地进行一些梳理，打算于10月30日和11月20日上午进行介绍，届时也欢迎我的同事以及华师大的研究生一同参与交流（时间可能会有变动，地点也未定，如您感兴趣，请关注本博客的更新）。

10月30日的讲座大纲目前考虑包括如下十二部分内容（这是个雄心勃勃的计划，如介绍不完，将顺延至下次）：

1、DCMI组织机构的变化
自从写完那篇《DC元数据的历史、现状和发展》一文之后发生了哪些变化，为什么。
2、DC元数据应用纲要（DCAP）方面的进展
主要是两个AP的规范文档以及两个三个AP实例（其中一个是草案）。
3、DC元数据抽象模型（DCAM）
为什么及是什么
4、元数据描述的新加坡框架
为应用纲要提供理论基础，回答“一个实用的元数据方案应该包含哪些内容？各类内容的关系是什么？”的问题。
5、元数据描述集的定义（DSP：Description Set Profile）
为什么需要DSP？与应用纲要什么关系？
6、DC元数据编码
包括XHTML、XML、Text、RDF四个编码规范。
7、语义互操作层次
同一组属性集在编码和约束上的不同规定决定了互操作程度的不同，据此区分语义互操作层次。
8、部分元数据应用项目简介
主要是这两年DC年会的案例以及应用了DC元数据的项目汇总。其它不用DC元数据的项目也需要做些介绍。
9、元数据应用相关工具
包括生成工具、转换工具、映射工具、抽取工具、质量控制工具等。
10、关联数据是一种元数据
图书馆有哪些数据值得做关联数据？
11、元数据与规范控制
元数据与本体术语体系，规范控制如何实现？
12、RDA作为一种元数据方案（规范但不是格式）
哪些地方用到了/借鉴了DCMI的元数据方法论？比AACR2有什么大的变化？

代码示例2：DCq编码实例

keven — Tue, 04 Dec 2007 09:09:12 +0000

The Dublin Core Terms Namespace providing access to its content by means of an RDF Schema.

The Dublin Core Metadata Initiative

The Dublin Core Terms namespace provides URIs for the Dublin Core Element Set Qualifier Vocabulary. Vocabulary terms are declared using RDF Schema language to support RDF applications. The Dublin Core qualifiers form a richer vocabulary, which is intended to facilitate discovery of resources. It will be updated according to dc-usage decisions.

English

2000-07-11

2002-05-24

Audience

A class of entity for whom the resource is intended or useful.

A class of entity may be determined by the creator or the

publisher or by a third party.

2001-05-21

2002-06-15

Alternative

Any form of the title used as a substitute or alternative

to the formal title of the resource.

This qualifier can include Title abbreviations as well

as translations.

2000-07-11

2002-06-15

Table Of Contents

A list of subunits of the content of the resource.

2000-07-11

2002-06-15

Abstract

A summary of the content of the resource.

2000-07-11

2002-06-15

Created

Date of creation of the resource.

2000-07-11

2002-06-15

Valid

Date (often a range) of validity of a resource.

2000-07-11

2002-06-15

Available

Date (often a range) that the resource will become or did

become available.

2000-07-11

2002-06-15

Issued

Date of formal issuance (e.g., publication) of the resource.

2000-07-11

2002-06-15

Modified

Date on which the resource was changed.

2000-07-11

2002-06-15

Extent

The size or duration of the resource.

2000-07-11

2002-06-15

Medium

The material or physical carrier of the resource.

2000-07-11

2002-06-15

Is Version Of

The described resource is a version, edition, or adaptation

of the referenced resource. Changes in version imply substantive

changes in content rather than differences in format.

2000-07-11

2002-06-15

Has Version

The described resource has a version, edition, or adaptation,

namely, the referenced resource.

2000-07-11

2002-06-15

Is Replaced By

The described resource is supplanted, displaced, or

superseded by the referenced resource.

2000-07-11

2002-06-15

Replaces

The described resource supplants, displaces, or supersedes

the referenced resource.

2000-07-11

2002-06-15

Is Required By

The described resource is required by the referenced resource,

either physically or logically.

2000-07-11

2002-06-15

Requires

The described resource requires the referenced resource to

support its function, delivery, or coherence of content.

2000-07-11

2002-06-15

Is Part Of

The described resource is a physical or logical part of the

referenced resource.

2000-07-11

2002-06-15

Has Part

The described resource includes the referenced resource either

physically or logically.

2000-07-11

2002-06-15

Is Referenced By

The described resource is referenced, cited, or otherwise

pointed to by the referenced resource.

2000-07-11

2002-06-15

References

The described resource references, cites, or otherwise points

to the referenced resource.

2000-07-11

2002-06-15

Is Format Of

The described resource is the same intellectual content of

the referenced resource, but presented in another format.

2000-07-11

2002-06-15

Has Format

The described resource pre-existed the referenced resource,

which is essentially the same intellectual content presented

in another format.

2000-07-11

2002-06-15

Conforms To

A reference to an established standard to which the resource conforms.

2001-05-21

2002-06-15

Spatial

Spatial characteristics of the intellectual content of the resource.

2000-07-11

2002-06-15

Temporal

Temporal characteristics of the intellectual content of the resource.

2000-07-11

2002-06-15

Mediator

A class of entity that mediates access to the

resource and for whom the resource is intended or useful.

The audiences for a resource are of two basic classes: (1) an

ultimate beneficiary of the resource, and (2) frequently, an

entity that mediates access to the resource. The mediator

element refinement represents the second of these two classes.

2001-05-21

2002-07-13

Date Accepted

Date of acceptance of the resource (e.g. of thesis

by university department, of article by journal, etc.).

2002-07-13

Date Copyrighted

Date of a statement of copyright.

2002-07-13

Date Submitted

Date of submission of the resource (e.g. thesis,

articles, etc.).

2002-07-13

Audience Education Level

A general statement describing the education or

training context. Alternatively, a more specific

statement of the location of the audience in terms of

its progression through an education or training context.

2002-07-13

Access Rights

Information about who can access the

resource or an indication of its security status.

Access Rights may include information

regarding access or restrictions based on privacy,

security or other regulations.

2003-02-15

Bibliographic Citation

A bibliographic reference for the resource.

Recommended practice is to include sufficient

bibliographic detail to identify the resource as

unambiguously as possible, whether or not the

citation is in a standard form.

2003-02-15

License

A legal document giving official permission to do something

with the resource.

Recommended best practice is to identify the license using a

URI. Examples of such licenses can be found at

http://creativecommons.org/licenses/.

2004-06-14

Rights Holder

A person or organization owning or managing rights over the resource.

Recommended best practice is to use the URI or name of

the Rights Holder to indicate the entity.

2004-06-14

Provenance

A statement of any changes in ownership and custody

of the resource since its creation that are

significant for its authenticity, integrity and

interpretation.

The statement may include a description of any

changes successive custodians made to the resource.

2004-09-20

Instructional Method

A process, used to engender knowledge, attitudes and skills,

that the resource is designed to support.

Instructional Method will typically include ways of presenting

instructional materials or conducting instructional activities,

patterns of learner-to-learner and learner-to-instructor interactions,

and mechanisms by which group and individual levels of learning are measured.

Instructional methods include all aspects of the instruction and learning

processes from planning and implementation through evaluation and

feedback.

2005-06-13

Accrual Method

The method by which items are added to a collection.

Recommended best practice is to use a value from a controlled

vocabulary.

2005-06-13

Accrual Periodicity

The frequency with which items are added to a collection.

Recommended best practice is to use a value from a

controlled vocabulary.

2005-06-13

Accrual Policy

The policy governing the addition of items to a collection.

Recommended best practice is to use a value from a controlled

vocabulary.

2005-06-13

Subject Encoding Schemes

A set of subject encoding schemes and/or formats

2000-07-11

Date Encoding Schemes

A set of date encoding schemes and/or formats

2000-07-11

Format Encoding Schemes

A set of format encoding schemes.

2000-07-11

Language Encoding Schemes

A set of language encoding schemes and/or formats.

2000-07-11

Place Encoding Schemes

A set of geographic place encoding schemes and/or formats

2000-07-11

Encoding Schemes

for temporal characteristics

A set of encoding schemes for

the coverage qualifier “temporal”

2000-07-11

Resource Type Encoding Schemes

A set of resource type encoding schemes and/or formats

2000-07-11

Resource Identifier Encoding Schemes

A set of resource identifier encoding schemes and/or formats

2000-07-11

Resource Relation Encoding Schemes

A set of resource relation encoding schemes and/or formats

2000-07-11

Source Encoding Schemes

A set of source encoding schemes and/or formats

2000-07-11

LCSH

Library of Congress Subject Headings

2000-07-11

2002-06-15

MeSH

Medical Subject Headings

2000-07-11

2002-06-15

DDC

Dewey Decimal Classification

2000-07-11

2002-06-15

LCC

Library of Congress Classification

2000-07-11

2002-06-15

UDC

Universal Decimal Classification

2000-07-11

2002-06-15

DCMI Type Vocabulary

A list of types used to categorize the nature or genre

of the content of the resource.

2000-07-11

2002-06-15

IMT

The Internet media type of the resource.

2000-07-11

2004-12-17

ISO 639-2

ISO 639-2: Codes for the representation of names of languages.

2000-07-11

2002-06-15

RFC 1766

Internet RFC 1766 ‘Tags for the identification of Language’

specifies a two letter code taken from ISO 639, followed

optionally by a two letter country code taken from ISO 3166.

2000-07-11

2002-06-15

URI

A URI Uniform Resource Identifier

2000-07-11

2002-06-15

DCMI Point

The DCMI Point identifies a point in space using its geographic coordinates.

2000-07-11

2002-06-15

ISO 3166

ISO 3166 Codes for the representation of names of countries

2000-07-11

2004-12-17

DCMI Box

The DCMI Box identifies a region of space using its geographic limits.

2000-07-11

2002-06-15

TGN

The Getty Thesaurus of Geographic Names

2000-07-11

2002-06-15

DCMI Period

A specification of the limits of a time interval.

2000-07-11

2002-06-15

W3C-DTF

W3C Encoding rules for dates and times – a profile based on ISO 8601

2000-07-11

2002-06-15

RFC 3066

Internet RFC 3066 ‘Tags for the Identification of

Languages’ specifies a primary subtag which

is a two-letter code taken from ISO 639 part

1 or a three-letter code taken from ISO 639

part 2, followed optionally by a two-letter

country code taken from ISO 3166. When a

language in ISO 639 has both a two-letter and

three-letter code, use the two-letter code;

when it has only a three-letter code, use the

three-letter code. This RFC replaces RFC

1766.

2002-07-13

NLM

National Library of Medicine Classification

2005-06-13

关于DC元数据的XML模式

keven — Sun, 02 Dec 2007 22:50:08 +0000

江汇泉老师在我的上一篇帖子中留了一个关于DC元数据XML模式的深度讨论，非常好的一个帖子，不知为什么被列入了“待审核”评论中，所以今天才得以“解放”，抱歉一个。后面谢涛老师的系列讨论，思路清晰，论述精彩，强烈推荐！因此给予“特殊待遇”，单列此帖。（顺便一说：本人的这个博客可以自由注册，如果需要单独展开议题，注册后应该即可发帖，如有问题请留言或发email。）

看完几位老师的留言，除了下面拉拉杂杂的留言之外，希望大家能够多关注并仔细领会DC元数据抽象模型，以及基于这个模型的新的编码规范的讨论（参见Expressing Dublin Core metadata using XML，以及DCMI Architecture Wiki）。同时希望共同探讨：独立与信息系统的、基于RDF/OWL描述的“语义层”是否有可能单独建立，从而使得应用系统的功能实现（如检索、浏览等）与内容描述完全分离？

江老师的原帖如下（同样，粗斜体为我的评论）：

受刘所之命，移师此帖中进行讨论。
非常赞同应该关注XML Schema或XMLS的意见。先就之前话题的回复谈点看法，并在后面，详细分析DCMI的Schema。

针对“因此DC元数据的XML表达（包括RDF表达）从数据上看起来是平面的，但是其结构和语义是用XMLS来约束的（如果是RDF，扩展的元素用RDF Schema进行定义），因此不能认为它是平面的。”

我的看法：XML表达，从数据来看都是线型的。但线型的数据，可以简单表达一层或二层数据结构，也可通过嵌套，表达出立体的、多层结构。

从数据交换来看，离开了XMLS的XML是无意义的，即使同采用了dc:title这类DC名称，即使从数据样例来看完全一样，从理论上讲，也不能肯定其是完全一样的。只有符合同一个XMLS的约束和定义的数据，才能说它们是一致的。但并不能说因为采用XMLS约束了平面的数据，所以数据就变成了立体的而不是平面的。因为XMLS仅是对数据的一种约束和定义，数据是平面的，则XMLS就表达了这种平面结构的定义和约束，反之，则XMLS就表达了这种立体结构的定义和约束。（当然，表达立体、层次概念的XML Schema是一定能够表达平面关系的，dc.xsd就是这样。我的表达不严密，被纠住了辫子，呵呵）

针对“这也就是说，DC元数据的形式化描述中，dc:alternative看起来与dc:title处于一样的地位，但实际上是完全不一样的，在XML文件的根元素指向格式解析模式中（通常是一个形式化的元数据应用纲要），可以明确它们的上下位关系。”

我的看法：如果是当前DCMI推荐的限定性DC形式化结构，即dc:alternative看起来与dc:title处于一样的地位，那么，在XMLS中，也是一样的地位，而无法确定它们的上下位关系。这点我将在后面的XMLS分析中进一步说明。（看了你后面的说明，由于我的确没有对DC的XML编码进行过实践，看来你说的是正确的，即目前DCMI推荐的XML Schema中确实没有反映出dc:title和dc:alternative之间的上下位关系，但是就我从DCMI中得到的印象来看，这是不应该的，即XML Schema如果不表示出这种关系，它就无法实现dumb-down。我会就这个问题去问一下DCMI的相关人员。）

关于我所谓“总在语义层面中纠缠”的感慨，仅是从纯技术层面角度来看，信息编码的根本目的仅是为了让计算机更易识别，所谓可读性更主要是指数据结构清晰无歧义、计算机处理效率更高。而不是指标识符带语义以及这种结构表达出某种语义——因为这些东西是人为赋予它们的。

所谓语义，我看用鲁迅谈及《红楼梦》的一句话来评论比较贴切：“经学家看见《易》，道学家看见淫，才子看见缠绵，革命家看见排满，流言家看见宫闱秘事”——计算机将元数据编码组合后，它们表达的语义，完全视用户或行业的约定俗成而定罢了。我是赞成谢涛同志所谓“大家讨论的许多问题可能确实和编码层面无关。因此建议可以先把编码层的实践方向和细节搞清楚，从而就可以开始行动了，具体语义和如何细节著录的事情可以继续吵，但是软件纹丝不动”的观点。都没有一个确定的编码组合，何来语义？“我”、“爱”、“你”——没有一个固定的组织方式，那么可以表达出“我爱你”、“你爱我”甚至引申为单相思或两情相悦等多种语义。

当然，结构清晰无歧义的编码，可以帮助人们实现语义的表达，这就是我们追求某种合理的数据结构或数据封装的原因。

（RDF/S及建立在它基础上的编码，如OWL/S等，是专为表达语义和逻辑而设立的，当然，你说得没错，计算机是不懂语义的，计算机表达语义也是通过事先约定的属性和关系——可以定义为机器语义，计算机处理从以字符元素，到文档(XML)元素，到语义元素，在思想方法上是完全不同的，可能跳跃得快了一些，需要进行一下Paradigm shift。语义Web的基础技术，就是为了解决您举的《红楼梦》的例子所存在的问题，目前所做的，只是希望通过表达语义的约定，尽可能解决计算机之间的语义传递问题。从原理上来说XML/S是无法做到这一点的。James Hendler有一句名言：A little semantic goes a long way. 的确如此，许多搞计算机的并不理解这一点，而情愿不厌其烦地建造信息孤岛，永远做机器的奴隶。计算机高手们不认同，也是造成目前SW发展艰难的一个重要原因）

针对“这与目前成熟的计算机软件系统体系架构有关，具体的应用都要采用成熟的技术，因此直接用XML编码的应用很少，DC大多作为一种交换格式，于是编码的一致性就显得不是那么重要的，谁都可以自定义”

我的看法：正是因为DC大多作为或将要作为一种数据交换格式，那么强调编码的一致性就非常重要——这个编码并不是说系统内部存贮或编码格式，而是说输出或交换时的编码格式。所以，不管系统开发者采用或拙或巧的数据库架构，只要想交换，就得采用某种一致的编码方案。不管是采用先形成数据，再形成统一的编码方案，并以这种统一的编码方案转换和规整已有数据，还是先形成统一的编码方案，以这个方案指导产生数据，最终得有一个统一。DCMI并不关心编码，这是它想兼包并蓄的理想，但我认为具体行业应用时，还是得有一个可操作的编码方案。

（很高兴你们一直有这样的想法，这是一种远见，与我的观点没有不同，我只是说出了“其他人”的观点，呵呵）

好比不管如何批评MARC的落伍，起码人家有ISO2709、MARCXML这种编码方案，就省去了学术之争与技术实现困扰。这也是我寄望我们国标制订机构或行业专家们能给我们一盏明灯而不是让我们摸着石头过河的原因。

针对“推荐 DC元素与元素限定词都编码为XML元素，采用QName，通过所引用的namespace来隐含表达元素与限定词间的关系（正如后面谢涛所说，这样倒反而不是“隐含”，而是通过XMLS显式地定义。当然，只是说法而已）”

我的看法：我所谓的隐含关系是指——QName可以看作指明元素的命名空间，比如dc:title和dcterms:alternative，通过http://purl.org/dc/elements/1.1/和http://purl.org/dc/terms/，可以找到title与alternative的定义，并获知这两个词汇间的关系。这种关系并不是通过数据格式或编码表现出来的，所以我说它们是隐含的。（我之所以强调不是隐含表达，因为“显式地、外在地表达”是元数据语义编码的一个重要原则，在具体应用中，必须通过QName、XML/S或RDF/S等各种手段，显式地表达语义关系，否则就可以认为这种关系不存在。DCMI近年来在编码规范讨论过程中所做的一系列改变，很大程度上是为了这一点。）

针对“我不同意你的看法，如我前面“摘要”中3、4、5所言，这样做正是为了更清晰地表达关系，而且，内容结构与数据文档保持各自的独立性，对于数据的生命周期管理，如对于XML内容结构修改变化的版本管理，有极大的好处。即：可以用不同的Schema读相同的数据，而不需要数据作任何更改”

我的看法：可能是因为我的“隐含”说法让你误认为我不重视数据以外的XMLS这个内容结构定义文件。事实上恰恰相反，我更关注这个XMLS。有时，为了表述元数据元素间的关系，在言语的贫乏下，XMLS语法就成为我的救兵。对于你“内容结构与数据文档保持各自的独立性，对于数据的生命周期管理，如对于XML内容结构修改变化的版本管理，有极大的好处。即：可以用不同的Schema读相同的数据，而不需要数据作任何更改”的表述，我想补充一点理解——结构定义与数据文档确实是相互独立的，但它们是相辅相成的。关于它们间的关系，似乎容易引起类似先有鸡还是先有蛋的争论。而我认为没有规矩不成方圆，事实确定一个结构定义，以此规范相应的数据文档更宜。因而，我认为一个规范的元数据体系，其数据结构的定义就不应该有摇摆性，所谓用不同的Schema读相同的数据，而不需要数据作任何更改的“好处”无从谈起——因为只要不同的Schema定义的数据，即使看起来相同，也应该看作不同的数据（你如何确定其中可选的数据差别呢？）——这点类似你评论谢涛的“一个修饰词只能修饰一个元素，即使它们形态上一样，也必须认为是不一样的”。再从语义打个比方，同是title，对于人事管理体系来看，它可能指的是头衔，而对于图书馆体系来看，它可能指的是题名。

实际应用中，对于资源的描述内容，即数据文档可能有不同，但应该且必须受同一个Schema文档的规范和约束——我的这个表述，可能与你“可以用不同的Schema读相同的数据，而不需要数据作任何更改”的表述刚好相反。用不同的Schema读相同的数据，正是我认为导致DC应用混乱无序的最大症结。林林总总的数据样例，居然无法用同一种Schema来定义或表述其结构。不同人的眼中有不同的哈姆雷特——DC应用中的这种摇摆性，看起来讨好了不同的观点，将只要标榜自己是DC的应用都纳入自己的阵营，貌似强大和影响广泛，但这种阵营总是不堪一击的。于是，采用无歧义的简单DC，就被垢病为不足以详细描述资源；采用随意且不经约束的限定性扩展，就被垢病为跟扩展MARC字段有什么两样？先进性何在？联想起“一个中国，各自表述”，看起来相安无事，但统一遥遥无期。如同谢涛所说，不管什么样的数据，计算机都可以处理。但有某种规范和唯一性，才有数据交换互操作性——即使这种规范和唯一性有些不合理，为了保证数据交换，我们首先得认同它。当然，如果理由充分，完全可以用更合理的规范和唯一性来取代旧的规范和唯一性。或许这也是我特别希望在行业应用尚未起步或大规模起步时，能通过交流或辩争，提前形成一个更合理更规范的数据结构定义，从而防范日后的积重难返——简单的比方，LCMARC定义之初，由于没有意识到计算机的强大，在字段内容中添加了ISBD分隔符。数据的积累，导致取消分隔符或兼容它的成本过高，然不取消它则著录成本也不菲。

(可能我的表述不太准确，让你有所误解。1、不同XMLS读取相同的数据是可能的，这里面不存在1:1原则。举例来说，用dcterms.xsd来处理dc.xsd的数据，理论上毫无问题。DCMI建立抽象模型的一个目的，就是不同的编码达成语义上的一致。2、不同XMLS共享复用，当然其中要处理兼容性、以及dumb-down问题。这可以由XSLT作映射来动态解决。不论哪种方法，实际上都能解决格式/模式与数据的独立性问题。你说的歧义，多不是由模式造成的，而是由元素定义–包括Domain/Range的定义–的模糊性和元素之间关系的不确定不兼容造成）

那么，现在我试着分析一下当前DCMI提供的Qualified DC XML Schemas（http://dublincore.org/schemas/xmls/）：

先在dc.xsd中，定义了一个SimpleLiteral数据类型：

即不允许下面有子元素，可以带一个xml:lang属性。
再定义了一个抽象元素any，并赋予它SimpleLiteral数据类型：

any是抽象元素，在数据实例中是不允许出现的，所以它仅是一个占位符，目的是方便后续的元素定义。
15个DC元素通过置换组定义，实现对any元素的替代，因而自然就继承any元素的数据类型：

再在dcterms.xsd，通过导入dc.xsd，从而可以引用dc.xsd中的定义：

然后再通过置换组，实现限定词对相关DC元素的替代，因而也自然继承了相关DC元素的数据类型：

可以看出，DCMI提供的Schema如此定义，自然如下数据实例就是合法且有效的：
xmlns:dc=”http://purl.org/dc/elements/1.1/”
xmlns:dcterms=”http://purl.org/dc/terms/”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=”http://example.org/appqualifieddc/ appqualifieddc.xsd”>

TITLE

ALTERNATIVE

SUBJECT

这也是我们在开发过程中，在没有得到官方支持或行业应用支持的时候，首先需要兼容或输出的数据样例——至于系统内部如何采用更合理更有技巧性的存贮格式，就是八仙过海各显神通了。

然而：

等价于：

所以，刘所认为通过Schema文件能看出平面数据的立体结构，以及看出显式表达出元素与其限定词间的关系是不太成立的。

（根据目前DCMI给出的xsd，你的上述说法是有道理的、正确的。我的说法的依据不是Schema文档，而是根据DCMI的“原则”，当然这些原则没有见诸文字是不可靠的。我以前根本没有仔细去看这些给机器用的文档，惭愧一个！值得注意的是目前的dc.xsd和dcterms.xsd看起来是不支持DCAM的，因为所有的属性都是作为Literal的，而不是resource。目前在DCAM中必须支持作为资源的属性和属性值的编码，也就是说这两个文档是我在深圳发言的PPT中所说的DCMI1.0，而不是2.0。因此在此提醒两位大侠，编码的模式可能于近期会修改。

说起上下位关系在XML模式中的编码，目前这样做是平面还是立体，因为substitutionGroup并不限定语义，是不是可以交给应用系统去实现上下位关系呢？因为如果没有这种上下位关系，在语义上是不符合DC元数据原义的，子元素不可以随便从属于多于一个元素，并且无法实现Dumb-down。）

上述两种Schema定义方式，都只能得出如下数据格式：
TITLE
ALTERNATIVE
即数据中dc:title与dcterms:alternative是平级的或平面的，在Schema中定义，它们也是平级或平面的。
至于认为采用substitutionGroup=”dc:title”而不采用substitutionGroup=”dc:any”，就可以看出alternative对title的继承或置换关系，仍只是一种从字面上理解而非技术上理解的思维。

我们再来看看假如alternative在具体应用中，还不足以深入揭示title细节，假如DCMI用更细的parallel、cover等表达并列题名、封面题名时，就得修改DCMI提供的Schema（注意，为了节省阐述篇幅，我没有用扩展的Schema来定义这些可能扩展的限定词，而是假设DCMI扩展。它们道理相同）：
即删除

增加：

同志们，可怕的事情来了！因为新的Schema文件，将无法验证旧数据了。当然，把旧数据按这个修订规则作一下数据转换、重构一下检索点也是能解决问题的。

(如果两个XML模式如上所说，需要达到互操作，可以有两个方法：1.无损的方法：一个大的包含所有元素及其约束的schema；2.有损的方法：都转换成一个中间的、用于互操作的schema。无论哪一种方法，模式与数据都是同等重要的，而且原始的、能够完整解析数据的XML模式无疑对于数据来说是最重要的。数据间的互操作，首先是在模式上做的。)

再看看我推崇的数据格式及其Schema：
先修改dc.xsd中的SimpleLiteral数据类型定义：

即增加一个可选的refinement属性，这个属性可选，其值为任意字符串。注意，这个属性也可以通过应用自定义的Schema定义，并在dc.xsd中导入这个扩展Schema即可实现属性引用。

那么，既然我们定义了一个值为任意字符串的refinement属性，就可以根据应用需求，存贮五花八门的限定词，而不需要再定义什么：

对于如下的数据，修改后的Schema都可以实现验证和约束（即我所谓同一个Schema约束多个数据实例）：
TITLE
ALTERNATIVE
PARALLEL
COVER
其中，refinement值可以不用QName，采用QName仅是为了照顾语义:-)

（你当然可以这样编码，在实践中也确实有各种各样的自定义方式，相比较而言，您这种可能还算是比较客气的，至少refinement可以看成是XMLS的保留字。然而由于DCMI的初衷就是对于元数据——包括资源的类型词表、元素、两类修饰词、甚至取值的规范，都进行规范，当然Literal是在规范之外的，你这样扩展的元素，只能属于DCMI能够关照的领地之外的了）

再看看表达同样语义的，DCMI推荐的数据样例与我推崇的数据样例的信息寻址优劣：
DCMI数据样例：
DATE
CREATED
VALID
AVAILABLE
ISSUED
MODIFIED

采用XPath对没限定词的日期寻址：
日期=”/dc:~~title~~date”
采用XPath对带限定词的日期寻址:
创建日期=”/dcterms:created”
采用XPath对带限定词的日期概括寻址:
其它日期=”/dcterms:created”+”/dcterms:valid”+”/dcterms:available”+”/issued”+”/dcterms:modified” //如果有更多限定词，需要修改寻址方式以实现穷举
采用XPath对所有日期概括寻址:
所有日期=”/dc:~~title~~date”+”/dcterms:created”+”/dcterms:valid”+”/dcterms:available”+”/issued”+”/dcterms:modified” //如果有更多限定词，也需要修改寻址方式以实现穷举

我推崇的数据样例：
DATE
CREATED
VALID
AVAILABLE
ISSUED
MODIFIED

采用XPath对没限定词的日期寻址：
日期=”/dc:~~title~~date[not(@refinement)]” //不带refinement属性的即为无限定词的日期
采用XPath对带限定词的日期寻址:
创建日期=”/dc:~~title~~date[@refinement='dcterms:created']” //refinement属性值等于dcterms:created的即为创建日期
采用XPath对带限定词的日期概括寻址:
其它日期=”/dc:~~title~~date[boolean(@refinement)]” //凡带refinement属性的即为日期的限定词，包括dcterms:created，dcterms:created，dcterms:valid，dcterms:available，dcterms:issued，dcterms:modified
采用XPath对所有日期概括寻址:
所有日期=”/dc:~~title~~date” //忽略refinement属性，包括dc:date，dcterms:created，dcterms:created，dcterms:valid，dcterms:available，dcterms:issued，dcterms:modified

前后对比，难道还看不出后一种除了在编码结构（注意，不是数据内容）上多些冗余，但在显式体现DC元素及其限定词间关系、表达“向下兼容”、以及系统寻址稳定性上，体现出强大的优势吗？（采用XPath属于应用层面的解决方案，从元数据规范层面来看，属于应该尽可能避免的权宜之计。）

谢涛老师留言：

1)

keven老师所说“因此DC元数据的XML表达（包括RDF表达）从数据上看起来是平面的，但是其结构和语义是用XMLS来约束的（如果是RDF，扩展的元素用RDF Schema进行定义），因此不能认为它是平面的。”我觉得部分可以认同。

我的理由是，XMLS表达了额外的意思，信息比单纯的数据记录来得丰富。例如keven老师所举的，从Schema中能看出一些蛛丝马迹，让人觉得element和修饰词之间是有“概念层级关系”的。

但是我觉得这些还不够，不是语义信息的全部。仍需要外在的人为的规则来帮助约束。

（编码规范应该“约束”到什么程度？一方面取决于描述模型应该“抽象”到什么程度，是否能够达成共识；另一方面又受限于形式化语言描述能力。当然，可以说XML作为一种元语言的表达能力是无限的，这就需要在复杂性与简单性、能力与需求之间建立一种平衡。上帝的归上帝，凯撒的归凯撒。标准规范所矛盾的地方，也就是在于划定一个界限。）

2)

在谈到语义层级结构的时候，需要注意语义上的层级并不对应数据实例中的结构层级。

比方说，alternative在概念上是title的下位概念，但是并不意味着在编码阶段要在alternative元素外面括一个title元素。

我举一个例子就可以说明问题：人类是从鱼儿进化过来的。一个胎儿在子宫中就模拟经历了全部的进化程序，但出生的时候，已经是一个人，而不是鱼儿。因此对应的说，从概念上alternative和title有“XXX化”的关系，但是在编码的时候，已经“出生”，语义和概念的演绎过程已经结束。也正好比端上餐桌来的菜，许多已经看不出原料。

所以我们眼睛看着一个DC element或者修饰词的编码实体，脑子里面可以想象它们的一切有关语义的事情，但不一定要追求“编码形式上的直白体现”。

但是编码层面也不是不能允许有特别的“结构”。我能想到的例子，就是同一个title，因为语种不同，不同的表现实例之间，它们实际上有紧密的联系 – 就是它们实际上都是用来描述一个东西的。好比孩子有大名和小名，看见两个名字并不是说有两个孩子，而是指同一个人。那么这时可以用一个类似这样的XML元素作为容器把它们包装起来。这样的设施在类似RDF这样的“发育良好”的框架下能够得到很好的表现。如果纯XML编码(非RDF等现有框架)要吸取这种特点，我不反对。

总之我暂时反对在编码层用某种结构表达江汇泉所举例的那些语义信息，而不反对用来表达其他的信息。

这里也顺便提到RDF和纯XML编码的关系：RDF看起来是XML，但是某种意义它已然不是XML。就好比豆子酿的酱油，酱油已然不是豆子。豆子不过是其原料。因此纯XML的原始性和自由性，像一片未开垦的处女地，容易让人迷惑，无所适从。（精彩的比喻！）

但是从时间和实践的发展看，使用纯XML的趋势是有的。可以理解为人们对RDF等实践后带着更多经验对纯/简单XML格式的一种回归。或者说一种“简约风潮”。

3)

我觉得DC的编码格式要少，要精。我们有理由扩展各种编码格式，但是理由要充分。

虽然随便定一个Schema就诞生了一个新格式，但是软件区读取这样一种新格式，是需要代价的，是需要编写代码的。

有人说通过XSLT可以在这些格式之间转换。但，没问题转换什么呢？本来如果不需要那么多格式，就不要先去造出来然后转换，这事情并不好玩。

目前的DC推荐的Schema，只是定义了非常非常局部的编码形态，它本身是允许这些局部和其他未定的XML文档结构糅合使用的。这种无为，也就是说不去定义全文档结构，也许就是一种好的办法，至少局部方面我们有一定的规矩。

只要一个具体项目用了dc或者dcterms的名字空间，就意味着认同这种简单的局部结构。这就不能随意了。所谓“可以自行扩展”，其实说的是XML文档的其他部分。比方说这些DC element物件的容器部分，根元素，DC是不做规定的。

所以从字面说，认为DC编码形态可以自行定义，那是一个误会，或者一个不精确的说法。其中的局部是已经定义死了的。

当然DC所推荐的编码方式也在发展。我们可以视为不同的版本。只要是同一个版本，那就是“死”的。

在编码方式有必要变化和扩充以前，肯定需要一个相对较长的稳定期，这对一个具体的项目很重要。

如果和ISO2709相比较，ISO2709的编码格式已经确定，在语义层面，字段名是留有扩充空间的。而XML格式的DC数据，一个是编码格式有不确定性，另外语义层面也有很大的扩充空间。尤其是前者给开发人员出了很大的难题 — 也可以说机遇与挑战并存。

希望在某些限定条件下，大家用的编码形式趋于一致，或在在少量的可选项中选择。否则数据可交换性就成了一个大问题。

当然这里的“可交换性”笼统说也不好。具体数据实例中，DC规定的那15元素的交换性还是不错的，如果都用DC推荐的编码方式的话。其他各系统自行扩充的部分，交换性如果不好，何以能怪到DCMI呢？这部分是“附带生发的情愫”，想想就明白了。

从XML技术细节的角度，在一个XML文档中，DC已经规定的那些element的编码对象，其位置层级的(潜在的)变化多端，并不构成对开发的难题。假如我们用XPATH寻找这样的对象，用一个“//dc:title”就能全文档寻找。

如果一个实际系统把这些编码对象进行了层级管理，但是另一得到这些数据的系统并不“以为然”，把这些对象理解为平坦结构，那么这“最低一层”的语义交换还是可靠的。前一系统关于层级关系的信息，属于“多余的表情”，被后一系统忽视了。这也是一个“好”的例子：毕竟该能交换的东西实现了能交换。

4)

keven老师所说“我不同意你的看法，如我前面“摘要”中3、4、5所言，这样做正是为了更清晰地表达关系，而且，内容结构与数据文档保持各自的独立性，对于数据的生命周期管理，如对于XML内容结构修改变化的版本管理，有极大的好处。即：可以用不同的Schema读相同的数据，而不需要数据作任何更改”我很赞同。

这是一个原则，对很多系统都适用。

江汇泉说“因而，我认为一个规范的元数据体系，其数据结构的定义就不应该有摇摆性，…”

我认为数据结构一旦定义，自然就是没有摇摆性的。比方说DC决定仅仅干预文档中的“DC能够管辖的部分”，这个原则就是没有摇摆性的。但是它是否对应用人员的心理带来摇摆的感觉，这可不一定。

正因为DC约束了自己的干预程度，其实总体来看DC彻头彻尾就是一个摇摆的定义，在编码结构上。它留出了空间给具体的系统，它绝对不去干预那些领域。这自然都带来了总体的摇摆性。

(这其实是DCMI提出元数据应用纲要(DCAP)的初衷：只关心它所能且该关心的，给别人也留口饭吃。网络世界观认为，大千世界，民主自由，异构是无限的。

但是，DC对于自己的领地，自认为一直立场坚定的，只不过认识有一个过程。DC立志成为语义Web(SW)的基本语义，SW尽管不同层级的表达能力不同，但唯一共同的基础是建立了整个因特网的相等关系：即基于命名域构成的URI而达成的同一性判断。其它的数学和逻辑基础，简单的已经建立（如包含，甚至否定），而大多（如相似、相近、甚至“相关”–概念间的距离等）则还在争论不休)

而且我们限定话题，针对“DC能定义、该定义”的那部分而言，也有一定语义层面的模糊性和可扩充性，说成摇摆性也行。

就如同我举例说明的，“OCLC”的全写是什么？可以有好几个附会的版本出现。类似的情况也发生在格式定义中。最低限度，是格式将来发展时打补丁的需要，我们没有必要歧视这种属性。

具体编码数据中关于语义和其他的线索信息很少，它于是自然允许后面的Schema等等一切设施作出某种新的“附会”和改进。编码数据中的字面信息(例如名称本身)是很明显的，这部分信息当然不能随便动。但是“后台”信息不在数据体里面。我认为这是自然的，有好处。

不同的系统甚至可以对语义作出自己别致的解释。但是也别对这一条太敏感。其实(元素)字面意义已经限定死了，能自由的空间是小空间。元数据集框架的巨大影响还在。这是说语义，而不是结构和形态。

5)

江汇泉举例试图说明XPATH下穷举不同的修饰词多么麻烦，而用冗余的元素名则可以避免这个麻烦。

以我的经验来看，创建那个穷举修饰词列表的事情，可以是软件完成的，而不是要人来次次“手书”。比方说具体系统有一个配置文件，软件写好一个循环程序，随着配置文件的些微变动(这变动当然可以由人进行)，循环自然能穷举当时该穷举的对象。这是“不费力”的。

也好比我们实际运行的系统中，SQL语句中的where子句都很复杂，但正是由程序中的循环过程来创建的，对人来说并不复杂。– 让机器对机器复杂去吧。

这一点小case，得不出“强大优势”的结论。

凡是都要算代价。精于算计不是什么坏事。我要和江汇泉算另外一笔帐：如果所用的编码格式中，XML元素名(对应于DC元素名)和 refinement属性的对应关系发生了变化，谁来负责修改数据本身？是江汇泉自己一一调出来数据修改几年呢，还是由一个批处理程序来修改？我们知道，一个具体系统，所用的元素集肯定在不断调整之中，语义和结构都可能调整。

而且所增加的冗余信息，完全是冗余的，是可以割除的阑尾。

宏大论述了语义和结构的关系，但是这个突发奇想的编码格式，我觉得和刚刚的宏大论述关系不大，成了“话锋一转”，突然谈论另一件不相干的事情了。

近期关于元数据编码的讨论

keven — Thu, 29 Nov 2007 08:12:55 +0000

警告：慎入！这个帖子会很长，主要涉及元数据编码细节的讨论。

承蒙谢涛和江汇泉两位技术大拿与远洋老师在我的博客上发起了热烈的讨论，所涉及的问题实在是在实践中非常重要，却很难武断地进行“推荐”。这里只能就我对DCMI编码的理解，夹叙加议，谈一点看法，希望国内这个领域的有识之士，例如参加过张晓林大组长标准规范课题的（像Leon、郑锡惠、徐周亚），以及CALIS国科图清华北大中科院等做过实践的，参与讨论。

本想在http://www.dublincore.cn/上讨论，但那是一个wiki，格式上不方便，这里讨论的结果将放到那边汇总。

需要说明的是，目前的“DC元数据XML编码指南”正在修订更新，将推出一个完全符合DCAM的规范，进行中情况请参见Expressing Dublin Core metadata using XML，以及DCMI Architecture Wiki 中的讨论(那里有大量的例子)。

摘要：

1、目前DCMI推荐的所有编码方案，均是尽可能遵循DCMI元数据抽象模型(DCAM)，DCAM是独立于编码、却为编码提供统一方案的数据模型。

2、目前争议的焦点实际上在于对这个模型没有透彻理解，以及对于基于XML、进而RDF的数据模型没有透彻理解。

3、XML的数据封装不能脱离XML模式（XML Schema或XMLS）或者DTD，也就是说所有包含XML实例序列化的数据原则上都需要XMLS或DTD才能让计算机读懂。而目前我们XML举例时通常直白地直接列出元素，似乎无需XMLS进行元素及结构的解析。这是不严格的。

4、因此DC元数据的XML表达（包括RDF表达）从数据上看起来是平面的，但是其结构和语义是用XMLS来约束的（如果是RDF，扩展的元素用RDF Schema进行定义），因此不能认为它是平面的。

5、这也就是说，DC元数据的形式化描述中，dc:alternative看起来与dc:title处于一样的地位，但实际上是完全不一样的，在XML文件的根元素指向格式解析模式中（通常是一个形式化的元数据应用纲要），可以明确它们的上下位关系，通常在如下的文件中规定格式：

6、应用系统在实现功能时，不应脱离XMLS去读XML文件。

7、拼音的编码方法：按照以前的做法（目前并不推荐），可采用修饰词的方式在XML中编码，如bo po mo fo。Akira在文章中给出了抽象模型的表示：

Statement (
PropertyURI(dc:title)
ValueString(汉字表示)
)
Statement(
PropertyURI(dc:title)
ValueString(Bo Po Mo Fo)
)
……

根据目前DCMI同行的做法，我猜想应该采用重复元素（字段），对属性值扩展Scheme词表的形式来说明，如扩展书写方式scheme为包含pinyin, hana, hanja, kanji…等编码的词表：Bo Po Mo Fo（如果词表有名称并需要标注的话，则编码稍微复杂些）。在正在酝酿的新推荐方案中，规定了封装的容器，弄得很复杂。

8、RDF编码的意义（完成中…）。

以上是我的理解和解释的大概。

以下是谢涛和江汇泉两位老师在我上一个帖子后的留言，干脆移到这里，并加上我的粗斜体议论（不断增加中）。（由于原文中许多代码含有<和>，拷贝粘贴时被浏览器吃掉了，我这里恢复的不一定正确，如有误请更正）

江老师留言1：

1、如我在“DC元素的中文翻译”曾有的“喜”、“忧”感慨。“DC元数据元素集国标项目”如果仍停留在DC元数据的最基本的15个元素语义，甚至纠缠在是否将DC元素名称翻译成汉语上，就真如同你所谓的“如果翻译了，就不是DC了（“盗版DC”？）”。对于具有高度民族自尊心的同胞们来讲，不要英文，要汉字的心情可以理解。几千年形成的汉字，丰富的语义和字形是我们的骄傲（玩话中有话和文字游戏，岂是那帮洋夷比得了得？），但对于直肠子的计算机来讲，可不如英文来得直接。并且，既是国家项目，也得上纲上线——港澳台同属中华大家族，这个DC元素名的中文翻译，是采用简体汉字还是繁体汉字？偏重一方都显得厚此薄彼，弄成简繁两套国标显然又是一种浪费。
3、概念的推敲与翻译，用许三多同志的话来质询，就是这种形为是否有意义。远洋的问题：“元素修饰词不知道是哪个英文词？Qualifier还是 refinement? 不过不论是哪个，都不应该是sub-element （子元素），对吗？”——我的理解是，Qualifier还是refinement类似“下岗”和“失业”，词不一样，但我们理解到它们的意思一样就行了。在标准中确定一个，意义虽不大，但总可以省些交流的麻烦。但如果弄成sub-element （子元素），可能就有点引入歧途了。因为，元素是元素，子元素也是元素，但DC为什么有元素与限定词两个体系呢？显然不是没有原因的。我的理解是，DC元素是用来描述资源的，而限定词是用来描述（限定）DC元素的，描述对象都不一样，sub-element概念除了误导外还有什么价值呢？（我同意不要误导之说，的确，把它认作独立的元素，然后与其它元素建立起上下位关系即可，本来就是一种让机器读懂的规定）

始终在想，为什么这么几个国字号的项目，总在语义层面中纠缠（元数据的目的就是要表达语义哦，以前表达不了，还不让现在表达啊？），就不能直白告诉我们如何在计算机中兑现和确定一个数据交换格式呢？（要知道所有计算机科学的进展，都是人和机器不断靠近的过程）作为系统开发商的我们，等得花儿都谢了（等待是值得的，机遇总是交给有准备的人）。如果我等草根阶层，在没有官方的指导下，弄些自定义的数据格式，又担心才思浅薄，误导我们的用户，更被日后官方格式制订者耻笑。所以，今天借刘所的宝地，提出几个问题，希望见多识广的朋友们能告诉我某些具体应用中的数据格式或处理方式，先谢过了：
1、请问DC应用中，如何处理汉语拼音？我得理解是应视汉语拼音为描述内容的规范体系或编码方案，采用类似：san guo yan yi的编码格式。请朋友们告诉我，是否在某个具体应用中看到过汉语拼音的编码格式，其数据样例是什么样的呢？（这个今年的DC会议上，日本人Akira Miyazawa专门发表研究了对这个问题的研究心得，讨论时Tom还是Mikeal说起，W3C也有人研究，我仔细考察过，再给你意见）

2、简单DC数据的XML编码，基本上没有异议。但对于限定性DC，就没看到有多少具体应用。但实际应用中，简单DC是不足以承担具体应用需要的更复杂的描述需求。那么，请问各位朋友，能否提供些具体应用中产生的限定性DC数据的XML编码样例？（这与目前成熟的计算机软件系统体系架构有关，具体的应用都要采用成熟的技术，因此直接用XML编码的应用很少，DC大多作为一种交换格式，于是编码的一致性就显得不是那么重要的，谁都可以自定义，等DCMI推出推荐意见之后，再on the fly修改）

3、DC官方网站中的“Guidelines for implementing Dublin Core in XML”，Recommendation 6. Element refinements should be treated in the same way as other properties. The name of the XML element should be an XML qualified name (QName) which associates the element refinement name with the appropriate DCMI namespace name. For example: 2002-06

推荐 DC元素与元素限定词都编码为XML元素，采用QName，通过所引用的namespace来隐含表达元素与限定词间的关系（正如后面谢涛所说，这样倒反而不是“隐含”，而是通过XMLS显式地定义。当然，只是说法而已）。对于这点我有异议，采用 XML编码是DC元数据的一种进步，因为XML是一种高度结构化的编码方案，通过XML结构，可以在数据内部清晰表达出元素与限定词间的关系，为什么非要采用外部的隐含表达呢？“言之不足，手之舞之，足之蹈之”——辅助手段是在主要手段不足时用，为什么非要舍本逐末呢？（我不同意你的看法，如我前面“摘要”中3、4、5所言，这样做正是为了更清晰地表达关系，而且，内容结构与数据文档保持各自的独立性，对于数据的生命周期管理，如对于XML内容结构修改变化的版本管理，有极大的好处。即：可以用不同的Schema读相同的数据，而不需要数据作任何更改）

我对如下限定性DC编码方案情有独钟：
2002-06
它的优势除了在于从结构化上清楚表达了元素及其限定词关系，更是忠实遵循了DC向下兼容原则——具体应用中，随便你扩充或忽略限定词，数据结构稳定、信息价值不会丢失。而推荐格式，除了少些数据冗余（这种数据冗余是结构上的而非信息内容上的，所以计算机处理时完全可以忽略不计），我看不出有别的优点。—— 当然，从语法转换来讲，这两种格式是等价的，但从对DC的理解来看，推荐格式显得比较矛盾。简单来讲，既DC明确了元素限定词不是元素（语义重叠的不能扩展为元素）(这里又是一个老问题：即元数据的元素与XML的元素不是一回事，元数据的元素和子元素都可以用作XML的元素)，那么，从形式来讲，用XML元素体现DC元素，再用XML属性体现出限定词（也就造成元数据的子元素不必表现为XML的限定词），这才有主次和差别之分嘛。何况，同为DC限定体系的编码规范体系限定（encoding-scheme），推荐又采用XML属性xsi:type来表示，岂非厚此薄彼不统一？参考推荐格式（这里实在需要强调一下：元数据的语义模型与编码可以而且应该分开，一样的模型可以用不同的编码，DC编码体系修饰词是对属性值的说明，当然可以用xsi:type来说明，非常自然，不必与其它修饰词统一编码方式）：
http://www.ukoln.ac.uk/

事实上，在2002/09/09发布的“Guidelines for implementing Dublin Core in XML”版本中，有以下的表述：
Recommendation 6. Element refinements should be treated in the same way as other properties. The name of the XML element should be an XML qualified name (QName) which associates the element refinement name with the appropriate DCMI namespace name. For example, use

2002-06
rather than
2002-06

但在2002/12/02以后的版本中，认为2002-06优于2002-06的表述就被取消了。只不过推荐以下格式：
foo

foo

明眼人都看得出，上述两种方式确实既冗余，又没“意义”。

我特别好奇，想了解一下作者对这个表述的修订本意是什么？然E文水平有限，担心对方听不懂——还望刘所或与我同样好奇的朋友替我与作者交流一二，并将结果转告与我——再次谢谢了。(一直没有研读DCMI最近正在草拟的更新版推荐)

最近，公司在开发DC编辑系统的“等米下锅”（寻求一种官方的、广泛应用的数据格式）过程中，为了降低开发成本，争取兼容常见DC数据格式过程中，有些慎重而严肃的争论和决策犹豫。因而对多年停滞不前，没实质进展的权威机构“不作为”行为更感郁闷，牢骚一多，就在刘所宝地吐了一地，还望见谅。希望此处的高朋能可怜我郁闷的心情，帮帮我，帮我找找实际应用中的限定性DC数据样例，多多益善——对于朋友的帮助，我们将回馈一个优秀的DC编辑系统供其本人使用。

江老师留言2：

仅从DC原则来理解——DC的原则是其立身之本，如果这个原则都有动荡性，体系也就不稳定了——我是支持远洋“元素修饰词不知道是哪个英文词？Qualifier还是refinement? 不过不论是哪个，都不应该是sub-element （子元素）”的说法。

简单分析，当前alternative作为title的限定词，显然语义限定还比较宽泛。当某日，需要把这个title的限定词更加细化，那么后出现的限定词难道应该成为sub-sub-element？这种理念下，编码是不易体现的——不可能在XML中同时出现title,alternative 与XXX等结构吧？如果出现了，如何体现XXX是title的限定词而非是alternative的限定词呢？

远望师“在DC中的refinements本身还不是一般有等级的那种sub-elements”的概念，是否意味着我钟情的类似编码有了更有力的支持？编码类似如下：
正题名
交替题名
从编码结构来看，正题名与交替题名是平级的——等级或从属是通过属性值来体现的。将限定词作为属性值，可以应对不同的需求扩展，更可以忽略这些限定属性，仍体现出大概念描述，这即所谓的向下兼容。

远洋师也是见多识广，能否帮我寻找更多的数据应用实例供参考。我们的本意是寻找一个更合理、更官方（更权威）的数据格式作为我们首先要对付或支持的格式。当然，如果没有这些数据，只得自行确定。但确定时，能有更多专家指导，总比我们闭门造车，孤陋寡闻弄些贻笑大方的数据格式好些。（找一些实践的数据格式可能很容易，但作用并不一定如您所想得那么大。具体的实例永远都是片面的，同样的XML经过输入输出也会面目全非，谁的责任呢？现在OCLC自己还没有“最佳实践”，怎会有“最准确的数据” 。当然，我们不能因此不去努力）

谢老师留言1：

在博客上短短数语发表意见，可能前后的语境不见得清楚，不过我还是尽量讲清楚。

DC在两个方面耐人思量：一个是语义方面。比方说alternative和title之间确实有不同寻常的关系。另外一个是编码、物理结构方面。比方说现在DCMI推荐的编码的guidline，把alternative和title并置，从形态上看起来是差不多的平起平坐的东西（没错，正是！）。

从软件实现的路径来看，首先是形态上的理解和兼容，能够存储数据，能够直白地检索（软件实现人员一般都这样考虑，而标准制定则不这样，考虑更多的是系统架构方面的问题。首先架构分层，语义与结构分离，表现与存储无关）。

所谓直白地检索，就是说你要我检索title，我就检索出title，你要我检索出alternative，我就检索出alternative，软件表现比较傻，比较单纯。

软件处理上然后下一个层次就是能够理解和处理语义关系。比方说在某种情况下，软件需要理解到alternative就是title的一种，能够扩检和缩检。所谓扩检，就是我笼统要title，软件能把alternative也算在内给我检索出来；所谓缩减，就是我看到广义的title检索命中结果很多，我希望缩小一点范围，专看精确属于alternative的那些。（软件难道不能通过Schema做到这一点吗？）

依我的经验，DCMI推荐的所谓元素和修饰词并置的编码方式，并不影响软件实现上述的第二层次。因为数据中，title和alternative在数据记录中没有明示的关系，在DC规则体系中，有暗含的信息表示。所谓“暗含”，是对于数据而言，因为数据没有明示，所以叫暗含。而对于DC的规则体系，是明确说了title和alternative两个概念之间的语义关系，这并不是“暗含”，而是明示。(关于这一点，前面已经说了)

对于DC数据的软件利用和处理，数据本身含有的信息和规则体系含有的信息都要参与作用。设想只通过数据就获得全部信息，是不可能的，也是没有必要的。（正是Schema与XML文档之间的关系）

江汇泉同志(请原谅我在这里使用他的真名，因为学术讨论似乎没有必要通过网名)偏爱类似

交替题名

这样的编码方式来表达修饰词，我想原因大抵是里面很有一些“附加”的信息，他认为这样对软件好，具体来说就是对于实现上述第二层次的软件功能有帮助。根据我的经验，这没有必要，软件本身不需要通过数据体内的某种信息来搞清语义，可以通过外在的信息来搞清(比方说含有某种规则的配置文件)。这种“好意”，实际上带来了数据的冗余，某种程度会增加软件的麻烦。

当然，我不反对在软件用户界面上，以某种形式揭示、体型用户关于title和alternative的语义关系，帮助用户录入数据和操作软件。但是这个任务不该和编码层次挂上钩，毕竟用户一般情况没有必要看到赤裸的XML数据。

实际上，我也是最近因为软件开发的缘故，看到DCMI推荐的平坦编码形态，才促使我思考关于修饰词到底是形容词还是名词这个比较深层次的问题。

从DCMI目前提供的dcterms语义、形态定义看，类似alternative这样的修饰词在语义类属上，只能属于一个element，而从未发现有从属于二个或者以上element的例子。我这个感觉如果有误，请指正。（一点没错，一个修饰词只能修饰一个元素，即使它们形态上一样，也必须认为是不一样的，必须给出不同的命名域。在DCMI的描述模型中，元素的domain和range决定了资源的属性不应该重叠交叉，因而子元素–姑且这样叫–不可能在一个方案里复用）

从我看到的这个现象，侧面证明了所谓修饰词的“名词”属性。也就是说，在讨论中，大家摆开了揉碎了说，可能alternative是一个类形容词的概念，可以和许多名词组合起来使用，但是在编码层面，任何落地了，也就是出现在类似XML文件中的物体，都是“名词化”了的概念。好比孩子出生后，就是一个自在的生命，但是要在中国生活，你得给他/她上户口，对不对？

从编码层面，目前的DC体系中，一旦落实到物理上的层次，都是名词。也就是说，如果一个形容词找不到和它结合的名字，就不能落地，就不能参与编码。

在DC体系中，这个“参与化学反应”的名词很显然：基本就是那个element概念。比方说，alternative要落地，它拉上它的语义关连对象title就可以了。这个规则是如此直白、简单，人和软件都会觉得它很漂亮。

如果我们强烈设想，alternative是一个形容词，我们甚至在编码阶段也要体现这个意图，让它明明白白和element例如title组合起来用，在编码阶段才组合，那么这恐怕不是现在的DC体系，而是一个大家设想的更好的元数据体系。所以我提醒大家不要把对DC未来的改进设想和对目前做法的阐释混淆起来。

如果alternative在编码层面真的是一个形容词，只需要一个证据就够了：你告诉我，alternative可以和两个不同的元素名结合使用。但是据我所知，没有这样的证据。

我之所以说江汇泉推崇的编码方式，元素名在里面是冗余，那时因为，在现在的DC体系中，alternative是title的修饰词，那是一句废话，是体系结构自含的，既然是废话就不要在编码中体现。

而如果确实DC原意是要把alternative当作形容词，alternative确实可以和不同的元素名组合使用，显现出千变万化的效果，那江汇泉推荐的编码方式就是显然和直白的了，毋庸置疑。但是我觉得这是一个误会，等于江汇泉编码出了一个设想中的可能未来的DC，和现在的DC不是一个东西，若加给现在这一代软件用，反而带来了无穷的烦恼。具体来说，就是这种编码方式所优势的“千变万化”的组合效果，正好是目前DC禁止的 — 一个修饰词能能老老实实属于一个元素，和一个元素进行语义组合，而不能和多个元素进行语义组合。(以上关于名词或形容词的探讨在我看来基本上没有必要，因为元数据只是机器语言，作为元素名称，都名词化了，不存在形容词的可能，修饰关系只是人强加给他们的)

我相信当然可能有其他元素有需要alternative的潜在需求。但是在目前DC框架下，人们只能寻找一个不同的词(哪怕意思本来就相似)，设定一个完全独立的URI，给那处需要的地方使用。（正是我上面说的道理）

如果因此认为DC这样的语义表达方式笨拙，那也没有办法。不过至少，这种“初等”的表达方式，是目前软件开发技术所习惯的，虽然不高明，但是还可以用。（我倒认为这正是DCMI的高明和精彩之处）

这个讨论真不知如何进行下去了，这边的帖子还没有改定，那边的留言又来了。下面是谢老师留言2：

说一个XML文档需要有XMLS来规范，我想这一点江汇泉体会应当很深(也有过不少实践)。（自底向上的考虑永远有无穷的复杂性，而自顶向下地抽象出描述模型往往能够豁然开朗）

好比我们在讨论C语言的编程，黑板上写写画画，大家很开心，但是一旦敲入计算机，用某个编译器进行编译，就会发现软件会理出一些错误和警告信息，回头来再检验自己的理解，发现计算机真是很“轴”，偏差一点都不行，必须得那样，不过也同时带来一些更别样的思考，对所谓“语言”的理解会更深。(编程语言永远是人适应机器吗？)

一个XML文档的编码规则要“落地”，最终还是需要落实到XMLS的编制、检验、测试上。有时候会发现本来说得好好的，但是一定义Schema时就暴露出一些含糊之处，或者Schema体系本身不允许的“超人”结构，那么这时候原来的意图就必须和现实的局限进行妥协。

一来二去，最终会订出一个人和计算机都比较满意的“实践最佳格式”。

有没有实在定义不出一个具体XMLS的XML文档格式呢? 当然是可能的。这就成为，我说它是怎样，它就是怎样，无严格规则可言，成为人嘴似乎可以说清那个格式，但是无法告诉计算机让计算机自己来精确弄清的浪漫局面。

XML文档基本格式合法，这是一个最低的要求，可以不去定义什么Schema。但是这样的格式一旦交流起来，要大家都去用，缺乏严格的定义，就容易造成创建文档和解释文档两环节的歧义。可以说没有定义Schema的XML文档格式，就是不方便交换和广泛应用的格式。

我们对DC的某种具体XML编码格式的要求，当然是希望它有个具体的Schema来限定最好。DC落地编码当然可以有多种具体的XML格式，但是我们出于交换的需要 — 因为DC生出来的一种重要使命就是用来交换数据的 — 势必希望最好有一种最通用的编码格式出现，大家熟悉它的Schema。这个Schema成为一个“准标准”。

~~~

这个Schema，它因为需要专心描述XML文档的结构，所以它在地位上是很接近“语义”的。但是我觉得它首先仍然是在解决编码的物理结构问题，觉得它非常和“语义”相关，有明显感情上的附会成份。

当然这不是说Schema这一工具对弄清语义没有好处，实际上很有好处。但是我还是宁可认为语义是在讨论桌上、空气中存在的，文章中自然语言论述的一种东西，可以部分附着在Schema上，但成份不是那么浓。

从一个格式的发展来看，有时候老版本的一些误会或者故意预留的空洞，会对后来的修订格式带来意向不到的好处，后来者可以去钻空子、附会、打补丁。这种效果有时候被安排成刻意的。

好比OCLC的缩写到底怎么来的？一开始时Ohio的几个图书馆的联合，后来附会成了Online Catalog，运气真不错。

我这样说的意思，是目前平坦化的DC在XML上的编码方式，其中有不少玄机，留给Schema或者语义专家将来可以玩弄的空间很大。这就是简单带来的某种好处。

数据一旦编制了，就是海量的，其格式难以说变就变。但是可以尽量不变数据，变Schema呀。平坦的格式虽然似乎没有把某些“资源”用穿，那正好也许是下一版格式制定的起点。

实际上从我自己从事软件开发实现的角度，我不太关心语义的精深议论，因为若有什么变化，也不太涉及到具体编码格式的动荡。（要知道你做的就是对于语义的编码，这在计算机过去的所有历史上都是没有的事情，这个事情是从现在才开始的，可能在国内，正是从你正在构想的软件开始的）

ISO2709格式可以装UNIMARC和USMARC，这两个格式在编目人员那里看来水火不容，但是在实现存储的时候，从开发人员眼里看来没什么太大差别。（这个比喻非常恰当和精彩！）

就说CNMARC，国家图书馆和CALIS的著录细节还有很多差异，编目员“明眼人”一看就能敏感觉察，但是从软件大部分角度，这些差异都不是本质的。

就是说我粗略觉得，大家讨论的许多问题可能确实和编码层面无关。因此建议可以先把编码层的实践方向和细节搞清楚，从而就可以开始行动了，具体语义和如何细节著录的事情可以继续吵，但是软件纹丝不动。（这可能吗？那我们就从两端开始吧：你从你的实践开始，我从我的模型开始，我真不知那样的话，我们哪一天才能见面！）

~~~

好了，我想请问大家：DCMI现在有没有这个XML文档编码的Schema？如果有，我想其中的意图可以先打开来领会，而不必盲目讨论了。（不好意思，现在没有。原因一：目前DCAM刚刚搞定，成为DCMI的推荐“标准”，费了老鼻子劲，他们希望这个东东能够超脱一切编码；原因二：DCMI并不关心编码，而把具体的编码交给DCAP，每个具体的应用都可以制定自己的XMLS，当然，最好是RDF/S）

如果浪漫设想了若干格式(变种)，却发现它们通不过这样的XMLS的校验，岂不浪费感情。(一个能够处理XMLS的软件工具，应该能够读入任何XMLS，生成相应的数据结构，动态产生表单和相应的展示界面…可能我的想法过于天真了，开发这样的“自动”工具，的确不是很容易）

这一步“上机实作”，不可省却。希望具体到这一层次进行探讨。

DC元素的中文翻译

keven — Sun, 11 Nov 2007 08:18:40 +0000

最近参加了汪东波老师主持、业界许多知名单位派代表参加的“DC元数据元素集国标项目”，顺便把我们经营了多年的“DC中文网”（改版前在这里）更新一下。最主要的工作是对DCMES (Dublin Core Metadata Element Set，即DC的非限定版)的ISO和NISO版本，以及几个中文翻译版进行比较，记了一些笔记。发布在这里，以期引起更多人的讨论和批评指正，并供大家参考引用。

以下修订笔记，记录于2007年10月21日，作为备忘，并供讨论参考。

1、建立了各元素单独的参考编辑页面以便逐个进行讨论修订。同时也建立了一个15个元素的汇总页面。

2、外链的标准规范文档需要在本地做镜像，以备网络或其他问题引起查考不便。

3、《都柏林核心元数据元素集(1.1版)》最新的中文翻译文档与原文档(2006年12月18日)在元素的说明体例上并不完全一致，因为当时中文版网站缺乏版本管理（没有用Wiki）而保留了部分原有的体例（例如“术语类型”、“状态”和“发布日期”等）。

4、ISO和NISO标准和中科院基本元数据项目对于元素的排列都是按照重要性（title, creator…），而DCMI是按照字顺(contributor, coverage…)，我们也将参照ISO、NISO的顺序对元素进行排列，而不是以字顺排列。

5、目前DCMI定义元素时，名称(Element Name)作为元素的标识(id)，是给机器读的。而标签(Label)是给人读的。因此前者都用小写，后者首字母用大写。目前修订过的ANSI/NISO Z39.85:2007和IETF RFC 5013都是这样，而中科院项目是把名称也翻译成了汉语，标签保留首字母可以大写。ISO 15836:2003还是名称和标签首字母都大写。

6、目前的文本在元素的定义和内容上尽可能与经过审核的最新的ANSI/NISO Z39.85:2007、IETF RFC 5013和Dublin Core Metadata Element Set, Version 1.1保持一致（经过核对，这三者是完全一致的）。DCMI中文网的文字上有与上述文档不一致的地方。

7、DCMES在修订过程中（如NISO Z39.85:2007），对于注释进行了简化，特别去除了具体的实例（例如identifier去掉了URI、DOI、ISBN举例）。考虑到GB需要添加实例，某些简化掉的内容可以添加到实例中。

8、由于目前在文本方面尽可能参考/采用新版的DCMES,有一些地方与ISO 15836:2003不尽一致，是否合适，需要项目组集体讨论。本人建议，因为ISO 15836:2003也即将面临Review，我们还是以尽可能反映最新的标准讨论成果为宜。