语义表达是不是一定要用RDF？
昨天参加了一场博士论文答辩，内容有关语义Web应用，论文架构很庞大，从基本概念、标准规范到元数据和本体的构建，到特定领域应用的实现和查询效果的比较等，感觉该童鞋很不容易。
答辩期间问了两个问题：
1、对于“语义”是如何理解的？机器如何理解语义？是不是Web加了元数据之后就是语义Web了？
2、如何对语义进行编码和查询？为什么没有试验用SAPRQLSPARQL进行查询？
第一个问题是因为论文中罗列了很多语义Web的定义而没有对语义进行定义，更没有说明语义是如何能被机器“理解”，保证机器理解的机制到底是什么？整篇文章给人的感觉好像是对于Web进行了元数据（语义）标注之后就是语义网了。
第二个问题是针对论文认为语义标注必须首先用XML进行结构化，RDF以及KOS转换的本体（OWL)起什么作用都没有明确说明，有点知其然不知其所以然的味道，后面更是没有提到语义Web查询语言SPARQL的独特作用，而是用SQL实现对语义数据的查询。
该 童鞋对于这两个问题的回答还是基本到位的，第一个问题她说到了语义就是所表达内容的含义，需要通过形式化编码才能被机器理解；第二个问题说需要用基于 XML的语义描述语言进行编码，因为在实验系统实现的过程中没有直接支持RDF的数据库系统，所以无法用SPARQL进行语义查询，等等。
这里想补充一些我的认识，有些认识可能比较绝对，对与不对大家可以批评指正。
1、 对于语义Web而言，RDF是基本的编码方式，是不是用了RDF可以作为具不具有明确外在的语义编码的判定标准。就是说，用了RDF，才能说是有语义的， 就像用了ASCII等字符编码标准才能进行文本编码一样。元数据可以不用RDF来表示，但是RDF是专门为了表达元数据而发明的语言（或者说框架或结 构），因为元数据就是“关于数据（主体）的数据（客体）”，主客体通过某种方式（谓词）相联系。这个问题在计算机界一直有争论，但是我这里对RDF的定义 是三元组方式，不一定是XML表达的三元组，也可以是其它方式（如N3等)表达的三元组，或者通过数据库方式能够输出三元组。本体OWL和SKOS都是基 于RDF的，因此它们肯定是表达语义的，而用XML自定义的任何表达方式，可以认为是系统内部局部的语义表达方式，到Web上就不具有可交换性了。因此它 虽然是结构化的，但不是表达全局语义的。
2、RDF是表达机器语义的必要条件，但并不充分。在语义Web中，必须结合URI机制，才能赋予任何一 个表达（资源）的全局语义，当然这个全局也仅仅是对于开放的Web来说的，这也就是URI能够解析的范围。任何一个局域网，无论其规模再大，都可能屏蔽这 种机器语义，而具有其独特的、更丰富的语义。因此，元数据和本体可以适用于比语义Web更广泛的领域，但到了Web上，这些内部语义如果要进行分享、重 用、交换，都有互操作问题。现有的技术架构、模型方案等，都是为了规范和减少这些互操作问题而提出。
3、采用了语义技术，语义Web就可能借助于SKOS或OWL等编码表达的概念体系，进行基于概念的检索，并可能进行知识挖掘和简单推理。SPARQL提供了强大的知识查询能力。
从理解XML到理解RDF，似乎在“思考范式”上要有一个转型。许多搞计算机的人都无法理解，对语义Web认识一直有一个障碍，就是“管它语义不语义，机器懂什么语义？系统只要能满足用户的需求，什么技术不能表达语义？”希望上述解释能够回答这个问题。
Popularity: 27% [?]
Tags: OWL, RDF, 元数据, 语义技术Related posts
《万物皆杂碎》
一直对《万物皆杂碎》（Everything Is Miscellaneous）一书充满好奇。据说6月份就出中文版*了，可现在还没见着。
“无界图书馆员” Karen Schneider对这本书的评论是：“这是一本危险的书，它会让我们图书馆员过去所学的一切都扔出窗外，让结构、秩序、精确的元数据、书目控制，这些统统滚蛋。”
作者David据说是一位著名博客，哈佛法学院伯克曼互联网和社会中心的研究员。David在书中提出“混乱也是一种秩序”、“混乱是一种美德”、“越混乱越有意义”，并认为网络数字世界正是这种”混乱”秩序的体现（简介如下）。
David认为无序（混乱）是世界上的第三种秩序，前两种分别是实体的秩序和理性的秩序。一本图书，一件家具，它们在各自存在于自己的位置之中，一次只能摆放在一个位置，如果放错了地方的话那就很难找到或者很不协调，这是实体的秩序。实体对象在人们头脑中的反映是第二种秩序，即理性的秩序，例如书目卡片、购物清单等，人们通过这种秩序来组织、学习、表述、传达知识。第三种秩序实际上是由第二种秩序的无限扩张而演变发展成的，反映了微观上的有序而宏观上的无序。
David的观点可以对我们有如下启发：
1、秩序是多元的；
2、数字时代不能再迷恋以最好的方式来组织世界，适用即好；
3、允许用户创建秩序；
4、图书馆必须接受现实，才有可能老树发新芽。
*该书由中信出版社出版，名为《万物因此而多姿多彩：新数字无序的力量》。
参考文献：
http://www.douban.com/review/1166344/
http://www.douban.com/review/1349754/
Popularity: 54% [?]
Tags: 2.0, 元数据, 笔记, 读书Related posts
元素名前缀的作用
谢老师的又一段评论被”关”起来了，现在放出来，并就自己的理解，加一点看法，同样不一定正确，望继续批评指正：
1、类似dc:title这样的元素名前缀我一直以为是不可缺少的，即在编码时dc与title共同组成一个有意义的XML元素(或属性)。
2、因此可以认为dc:title和dcterms:title是完全不同的，其相等关系隐含在DCMI的其它声明中，或者通过应用系统建立。
3、正如远洋老师前面说到过的，dc:alternative这个元素是不存在的，alternative只存在于dcterms中。
4、命名域xmlns指定了前缀的参考地址，使得元素具有了全域的唯一性，起到的作用正是谢老师在下文中所说的目录指向，只不过在广域网环境下、采用了URL的指向。
5、因为这里RDF是用XML来表达的（也可以用N3或者DC自己定义的DC-Text来表达），所以尊崇XML的所有的规定和语法，包括命名域和前缀的规定。
6、对于名称和翻译，我在深圳的报告 ppt第23页有一个盗版Stuart Weibel的图（如下），应该能够说明翻译的label在哪里解析的问题。
谢老师的评论主体（斜粗体为我的评论）：
Read the rest of this entry »
Popularity: 53% [?]
Tags: 元数据, 元数据, 编码Related posts
代码示例1
更新update: 远洋老师的另一个示例文档已经提供下载。昨天为了这些代码折腾了一个多小时，本来前面还有一大段话，一发布就都飞了，可能是因为代码中除了包含<、>之外，还有其它trick，抑或因为wordpress的bug（太长？）。大意是说，Leon提醒我XMLS的关系描述能力有限，需要描述语义层次关系恐怕还非得RDF，令江汇泉抓狂的原因恐怕就在这里，而不仅仅是DC的属性词表不够，等等。
远洋老师给的DC元数据编码示例（另一个例子实在没法放到博客上，您可以在这里下载）：
Read the rest of this entry »
Popularity: 53% [?]
Tags: 元数据, 元数据, 编码Related posts
关于DC元数据的XML模式
江汇泉老师在我的上一篇帖子中留了一个关于DC元数据XML模式的深度讨论，非常好的一个帖子，不知为什么被列入了“待审核”评论中，所以今天才得以“解放”，抱歉一个。后面谢涛老师的系列讨论，思路清晰，论述精彩，强烈推荐！因此给予“特殊待遇”，单列此帖。（顺便一说：本人的这个博客可以自由注册，如果需要单独展开议题，注册后应该即可发帖，如有问题请留言或发email。）
看完几位老师的留言，除了下面拉拉杂杂的留言之外，希望大家能够多关注并仔细领会DC元数据抽象模型，以及基于这个模型的新的编码规范的讨论（参见Expressing Dublin Core metadata using XML，以及DCMI Architecture Wiki）。同时希望共同探讨：独立与信息系统的、基于RDF/OWL描述的“语义层”是否有可能单独建立，从而使得应用系统的功能实现（如检索、浏览等）与内容描述完全分离？
江老师的原帖如下（同样，粗斜体为我的评论）：
Read the rest of this entry »
Popularity: 79% [?]
Tags: DC Metadata, 专业评论, 元数据, 元数据, 编码, 语义技术Related posts
近期关于元数据编码的讨论
警告：慎入！这个帖子会很长，主要涉及元数据编码细节的讨论。
承蒙谢涛和江汇泉两位技术大拿与远洋老师在我的博客上发起了热烈的讨论，所涉及的问题实在是在实践中非常重要，却很难武断地进行“推荐”。这里只能就我对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文件的根元素指向格式解析模式中（通常是一个形式化的元数据应用纲要），可以明确它们的上下位关系，通常在如下的文件中规定格式：
<xsi:schemaLocation=”http://example.org/mydiglibapp/ http://example.org/mydiglibapp/schema.xsd”>6、应用系统在实现功能时，不应脱离XMLS去读XML文件。
7、拼音的编码方法：按照以前的做法（目前并不推荐），可采用修饰词的方式在XML中编码，如<title.transcription>bo po mo fo</title.transcription>。Akira在文章中给出了抽象模型的表示：
Statement (
PropertyURI(dc:title)
ValueString(汉字表示)
)
Statement(
PropertyURI(dc:title)
ValueString(Bo Po Mo Fo)
)
……根据目前DCMI同行的做法，我猜想应该采用重复元素（字段），对属性值扩展Scheme词表的形式来说明，如扩展书写方式scheme为包含pinyin, hana, hanja, kanji…等编码的词表：<dc:title Scheme=”yournamespece:pinyin”>Bo Po Mo Fo</dc:title>（如果词表有名称并需要标注的话，则编码稍微复杂些）。在正在酝酿的新推荐方案中，规定了封装的容器，弄得很复杂。
8、RDF编码的意义（完成中…）。
以上是我的理解和解释的大概。
以下是谢涛和江汇泉两位老师在我上一个帖子后的留言，干脆移到这里，并加上我的粗斜体议论（不断增加中）。（由于原文中许多代码含有<和>，拷贝粘贴时被浏览器吃掉了，我这里恢复的不一定正确，如有误请更正）
江老师留言1：
Read the rest of this entry »
Popularity: 88% [?]
Tags: DC Metadata, DCAM, 专业评论, 元数据, 元数据, 编码, 语义技术Related posts
近期关于元数据的一些讨论
我没能完全理解，但就我的理解发表了一些理解：
1、元数据元素集是描述资源各个方面的属性词表；
2、元数据取值如果规定只能从某些词表中选取，这些词表就属于受控的规范词表；这属于元素取值的domain和range；
3、元数据应用纲要是为了领域应用而制订的元数据方案的一种表达形式，目前正在成为规范的，叫做“DC元数据应用纲要”，核心是符合DC抽象模型的元数据形式化表述（也就是一种机读形式），通常可以以RDF形式表达；
4、应用模型（规定应用领域的各类实体及其相互关系）、著录规则等文档，也可以成为元数据应用纲要的组成部分；
5、元数据注册系统可以作为元数据元素的命名域管理体系而存在，但命名域并非一定需要注册系统进行管理；
6、元数据元素词表，包括规定元数据取值的规范词表，都可以看成是一种人工语言，每个术语都应该被赋予唯一的URI，都可以通过注册系统进行管理；
7、元数据形式化的表达必须采用基于XML的RDF或OWL等的Schema，著录工作单当然可以通过完整表达元数据方案各种关系和约束的schema来自动生成，并进行校验。当然这需要一定的环境和软件工具来实现；
……
至于这几种元数据标准的分类，感觉在概念上有交叉，是从应用角度来分类，并不具有严格的意义。
前两天针对图林茶的困惑，也发表了一些看法（问题的陈述只是大致）：
问题1：目前针对具体应用领域制订的元数据方案，其描述对象究竟为何？
1a、任何具体的元数据方案所描述的实体，都可能是一个复合的实体，并在整个生命周期中具有不同的表现。完善的元数据方案应该首先有一个应用模型（如FRBR）进行清晰的表达，这样才有可能使得具体的描述符合1:1原则。
1b、应用系统在具体开发实现的时候，可能无法保证模型关系的完整体现，这已经在元数据方案所能考虑的范围之外了。好的实现，应该能够以较少的代价（例如一条记录），反应更多的内容（例如两种实体之间的关系）。
问题2：元数据方案不都是“描述”资源的吗？
2、元数据就是关于数据相关属性的描述，虽然有描述性元数据、结构性元数据、管理性元数据等说法，这里的“描述”取了狭义的“内容描述”的含义。纯粹玩弄词藻，就不多言了。然而属性的取舍是元数据方案的关键，不“困惑”这个，制定元数据方案就基本上没有可以困惑的了。
问题3：元数据的“元素”与XML的“元素”，究竟是不是一回事？
3、不要把元数据元素和XML中的元素混为一谈，虽然前者可以用为后者，当然，也可应用为后者的“属性”，这是编码的问题。元素与修饰词在元数据方案中都 是“术语”，都应该慎重，作为一种“元数据应用纲要”来说，复用原则是第一位的，自己添加的术语需要明确定义，并给出命名域（作为课题来说，要给出建 议），否则方案就是不完整的。
细究下去，还有许多进一步的理解，希望这次到深圳参加数图十年会议，能有机会能跟大家沟通一下，并得到大家的批评指正。
Popularity: 49% [?]
Tags: Metadata, 元数据, 元数据Related posts
DC元素的中文翻译
最近参加了汪东波老师主持、业界许多知名单位派代表参加的“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，我们还是以尽可能反映最新的标准讨论成果为宜。
Popularity: 100% [?]
Tags: DC, DC Metadata, Metadata, 中文翻译, 元数据, 元数据, 标准规范, 笔记, 都柏林核心元数据Related posts
“新加坡框架(Singapore Framework)”
沃维克框架、堪培拉限定、芬兰终结……。DC元数据自诞生以来，留下许多里程碑式的成果，如今这些成果中又多了一个：新加坡框架（Singapore Framework）。
新加坡框架是指元数据应用纲要的一种规范形式。虽然应用纲要曾经是欧洲标准CWA14855，但那毕竟只是一个非常笼统、给人作参考的“指南”。DCMI认识到DC的应用一直无法大规模开展，与编码方面的规范一直不统一很有关系，编码的无标准可循造成元数据标准有等于无，各类应用的互操作还是无法进行。然而编码规范的统一是一件不可能的任务，在XML大行其道的今天，任何符合XML模式规范的DC编码，你都不能说它不规范，你也不可能让大家都采用一种XML的DC编码模式。同时专注于语义一致性描述的DCMI怎么可能推荐一种编码而排斥另一种呢？再说现在有RDF/OWL/N3等编码方式（甚至采用关系型数据库来描述和编码），将来还会出来种种新的方式，如何能预料得到呢？所以对于编码的标准化，必须依赖于一种编码模型的标准化。这就是近年来DCMI花大力气研究并反复讨论的“DC元数据抽象模型(DCAM)”。只有独立于语言的编码模型标准化了，才能建立一种标准的形式化编码规范，不论形式化语言用的是什么。
而领域应用中符合DC抽象模型的元数据的形式化方案的整体，就叫做DC元数据应用纲要（DC Metadata Application Profile）。 我们的“专门元数据方案”实际上都可以认为属于领域应用的“应用纲要”。
具体说来，新加坡框架指符合DC元数据抽象模型的元数据应用纲要，应该包含以下几个部分：
–
- 功能需求说明(需要desirable)
- 领域模型 (必需mandatory)
- 元素集描述 (DSP: Description Set Prifile) (必需mandatory)
- 应用指南 (可选)
- 编码句法指南(可选)
对于每个部分是否必需Mandatory、需要Desirable还是可选Option，目前的意见还不统一，例如很多图书馆员认为功能需求说明应该是必需的，但是对于形式化的应用纲要，功能需求说明只是给人读的，不像领域模型（可用UML形式化）和元素集合描述等（DSP，用Schema等形式化），无法翻译成机器语言，对于机器来说并非必需。
为进一步说明应用纲要各个部分的关系，这里还有一个框架的图示（版权属于DCMI，本人拥有翻译版权，引用敬请声明），值得好好推敲和学习：
2004年本人在一篇论文中将数字图书馆的元数据描述方案定义为“语义结构(Semantic Architecture)”，并认为有如下几个部分组成：
- Resource Analysis and Definition
- Metadata Set Definition (Core and Extended)
- Encoding and Mapping Rules
- Guidelines and Best Practices
- Metadata Registry, Ontologies and Authority Files
与这个“新加坡框架”颇有一些异曲同工呢！
Popularity: 70% [?]
Tags: DC, 会议, 元数据, 元数据, 应用纲要, 新加坡框架, 语义技术