数图研究

一位叫Mingchi的朋友来信希望解释一些语义Web的东西，于是我们之间通了几封信。感到这些问题和解释可能对初次接触Semantic Web的朋友、特别是图书馆界的朋友会有一点用处，征得同意之后贴在这里：

我有在 http://blog.donews.com/ sayonly/archive/ 2005/10/28/ 605465.aspx看到您的comment，您在当中有提到一段话

「…浏览器对语义标注没有感知，所以才有RSS阅读器、FOAF插件等工具的开发…」

能请您方便多说几句吗？感谢

我在“只说”的博客上的完整留言是这样的：

传统的搜索引擎只是把网站和网页内容当成毫无结构的文本，只进行非结构化的全文查询。而越来越多的网站呈现出来的内容无法反映其底层结构和层次，网页只是应用的外表，随着越来越多元数据标准和开放协议的应用，越来越多的应用以XML形式呈现数据，甚而由于语义万维网的开放要求而能够呈现底层的应用模型和数据结构，这就会给目前的搜索引擎带来革命性的变化，即产生更加智能的、基于语义的搜索引擎。而这种搜索引擎极有可能是由分布式搜索引擎簇提供个性化的查询、浏览（Web2.0时代的搜索引擎），其功能需求的人机界面也将是目前传统的浏览器所无法满足的。许多语义Web的”语义”无法经由传统的浏览器读到（浏览器对语义标注没有感知，所以才有RSS阅读器、FOAF插件等工具的开发）。

尽管目前还十分缺乏”杀手级”应用，但是开发诸如带PiggyBank扩展的浏览器是浏览语义万维网应用”显性化”的第一步。

语义Web的发展并不如人们的预期，就像语义Web专家James Hendler 说的那样，a little semantic goes a long way。万事开头难，工具与应用就好比鸡与蛋的关系，特别是人们对一大堆标准规范还不能一致理解，而且由于一些理想主义原则的驱使，这些标准规范还不足以搭建完整的应用。

我的解释：

是这样，目前的Web应用所传送的代码实际上已经远远超越了HTML文本，虽然显示给人的只有其中的html部分（或者通过CSS/XSL等方式动态生成的HTML），许多机器代码或具有特殊语义的代码（例如许多微格式）都需要浏览器插件或其他方式（ajax）进行处理，方能获取。RSS、FOAF、hCard、hCalendar以及许多格式都是一些特殊用途的XML/XHTML代码，需要本地支持（通常可以通过js、jsp、asp、ajax开发的浏览器插件，如greasemonkey或其他客户端代码），而且这些开发最好是基于标准的，这样才便于共享、使用、推广，但是标准的建立不是一簇而就的，除了技术因素之外，遵循开放精神、尊重现有标准、由应用推动等都是其中的因素。

进一步的问题：

…去年Google base推出时，很多人认为这是Google走向SW的一步，…看到网络上大部分人的说法，主要是说Goolge base提供了让用户创作与发布内容的平台，且事先针对使用者可能填写的内容作项目上的定义或规范 (如：Details、Labels、Description与Location)，认为这有助于未来用户在Google base上的搜寻结果；但是我认知的是，其实像ebay等网站，过去也是提供一堆先定义好的项目字段 (价格、产品规格…等)，供使用者填写，那这样有什么不同呢？为甚么很多人提到SW，都会提到Google base？

因为看到很多人在提到SW的话题时，好像都认为Google Base是迈向这一步的创举？在我的感觉，会觉得两者是类似的 (但都没人将SW跟ebay之类的网站扯在一起)；当然明显的是，ebay着重在物品拍卖功能，Google base的范围广泛多了

我的讨论：

我对于被认为是SW的Google Base以及Google Swoogle等东西了解不多，我是这样理解的：

SW的特征并不在于是否进行了属性描述，传统的关系数据库应用都进行属性描述，你说的eBay就是这样，都要提供一定的功能让人进行”语义”检索。关键问题在于这种属性描述是否能够被机器识别，即你描述的”title”、”creator”等别的机器也要看得懂，或者知道你的”title”、”creator”就是他的”heading”、”author”，甚至知道你所参照的”creator=keven”就是指” http://my.donews.com/keven/”中的那个keven。

机器实际上是不可能”知道”语义的，机器对于语义的判断仅仅是”一致性”判断，不同来源的东西具有相同的URI，就认为是相同的，不同东西如果用isVersionOf, isPartOf等等，就指明了它们的语义关系。

由此可见，是不是SW的特征主要还是后台的：是否支持一种机器认可的语义编码（即RDF）以及是否建立形式化的语义关系（即利用OWL等本体语言）。我相信Google后台是这样做的，因为Google的野心是让大家都来建设内容，而它来整合大家的内容。它目前通过建立Google Base、Google Swoogle等平台让大家上载内容并进行语义注释（我们称为标引），将来eBay等其他公司如果支持SW了，它可以很快地集成到它的搜索体系中去。因为SW的标准是W3C的，是开放的，大家都会支持的。从这里可以看到Google的”险恶用心”。其他公司也肯定会相出种种办法维护自己的竞争力的，只是作为用户，希望不要破坏这些标准的开放性。

我的解释可能需要一些预备知识，对于没有计算机背景的朋友来说不够清楚。Mingchi朋友非常具有求知精神，而且非常乐意开动脑筋去考虑这些技术问题（最近在gtalk上也碰到一位好学的朋友，而且对于计算机已经具有相当专业的研究–居然已经读过”形式语言与自动机”之类的书籍，与我讨论语义Web的问题，并且询问了一大堆相关书籍说要仔细看看）。之后又收到他的来信：

我思考了一下，…Google base让用户在填写信息时，以结构化的方式去填写，若以SW的角度来看，目的在于方便后端的后设数据层去分析，来建立知识本体？

感觉如果SW成熟的话，似乎只要简单输入关键词，就会以现在大家常提的mashups方式呈现出搜寻结果，而这群mashups所秀出的搜寻结果，是以一种有意义的方式组合起来的…

我做了进一步解释：

原谅我没有说得十分清楚。Google Base会让用户以结构化的方式填写咨讯，eBay也会这样做，然而Google Base的后台是用RDF来存储这些咨讯的，而eBay可能用的是关系型数据库，这两者是本质的不同。当然eBay也可以把关系型数据库中的咨讯”翻译”成RDF形式，这就需要借助”后设资料”（我们叫”元数据”）的帮助了。如果需要更高级的功能就还需要知识本体Ontology。

如果SW成熟，Google Base就可以不仅查询用户在Google Base上存入的咨讯，还可以整合别家支持SW标准的数据，这可以看成是一种Mashup。

你的理解大致是不错的，我只是再多作一些澄清。

仓廪实而知礼节。这年头我们据说已不缺吃不缺穿，所以该补补我们最缺的东西–”德”了。有人说我们把腌菜当珍馐，呼吁大家”七不七建”、”八荣八耻”，简直就是呼吁大家不要禽兽不如，”德”的标准也定得太低了。而且以前也并非没有倡导，价值失衡道德失范有愈演愈烈之势，为什么越倡导越不灵验？在我看来恐怕是我们历来忽视个体价值和独立精神造成的，越是强调小我、无我、奉献、牺牲，人越是被工具化、欲望膨胀，就越加自私。越是尊重、承认个体的价值，就越能够尊重、承认别人的价值，就越能够建立良好的道德秩序。近日警察执法引起的媒体讨论已超出了具体行为本身，有人说矫枉必须过正，有人则认为过度执法所表现出的对人的不尊重正是造成道德失范的根源，莫衷一是。 然而以愚之见呼吁总比忍受好，讨论总比沉默好。近来单位要求人人能够默诵这些条条，虽然苦了k某这类不求上进之徒，然而还是心悦诚服，愿意好好学而时习之的。 于是上网查了这些道道，有些还是中英文对照，录在这里，供自己和大伙学习吧。

八荣八耻 Eight Honors & Eight Disgraces

以热爱祖国为荣、以危害祖国为耻， Love, do not harm the motherland. 以服务人民为荣、以背离人民为耻， Serve, don’t disserve the people. 以崇尚科学为荣、以愚昧无知为耻， Uphold science; don’t be ignorant and unenlightened. 以辛勤劳动为荣、以好逸恶劳为耻， Work hard; don’t be lazy and hate work. 以团结互助为荣、以损人利己为耻， Be united and help each other; don’t gain benefits at the expense of others. 以诚实守信为荣、以见利忘义为耻， Be honest and trustworthy, not profit-mongering at the expense of your values. 以遵纪守法为荣、以违法乱纪为耻， Be disciplined and law-abiding instead of chaotic and lawless. 以艰苦奋斗为荣、以骄奢淫逸为耻。 Know plain living and hard struggle, do not wallow in luxuries and pleasures

(外一首) 计算机道德的十条戒律 来源于Computer Ethics Institute

1. Thou shalt not use a computer to harm other people.不应使用计算机危害他人。
2. Thou shalt not interfere with other people’s computer work.不应干涉他人的计算机工作。
3. Thou shalt not snoop around in other people’s computer files.不应窥探他人的计算机文件。
4. Thou shalt not use a computer to steal.不应使用计算机进行盗窃活动。
5. Thou shalt not use a computer to bear false witness.不应使用计算机做伪证。
6. Thou shalt not copy or use proprietary software for which you have not paid.不应拷贝或使用没有付费的版权所有软件。
7. Thou shalt not use other people’s computer resources without authorization or proper compensation.不应在未经授权或在没有适当补偿的情况下使用他人的计算机资源。
8. Thou shalt not appropriate other people’s intellectual output.不应挪用他人的智力成果。
9. Thou shalt think about the social consequences of the program you are writing or the system you are designing.应该注意你编写的程序或设计的系统所造成的社会后果。
10. Thou shalt always use a computer in ways that insure consideration and respect for your fellow humans.使用计算机时应该总是考虑到他人并尊重他们。

蒂姆 伯纳斯 李（Tim Berners-Lee）在为WWW2006（第十五届万维网大会）预热接受 BCS执行经理采访时说的一些话很有意思，摘录如下：

• 关于”如果有机会重新回到十五年前，再次发明万维网，你会做哪些不同”这个问题，TBL说了两点：http:后面的两斜杠”//”是毫无必要的，另外他会把域名倒过来写（就像中国人写地址那样，大的地名在前），这样域名解析将会有许多不同（得到简化），并且一个大机构可以只拥有一台服务器，或者即使拥有多台，URL也可以相同。
• TBL认为”安全浏览器”是目前最能够影响到互联网各个方面的一项技术（有点出乎我的意料），”安全浏览器”是指能够识别用户身份，而不像现在这样仅仅连接可以加密，而并不知道谁在用浏览器。
• TBL说目前Web最大的三个课题是1、安全；2、移动Web；3、Web Services。
• TBL透露他平时喜欢用A0幅面的白纸写写画画，因而喜欢使用大屏幕，所以网页设计的进步能够在一屏中容纳更多的数据也令他感到高兴。
• 1web年=2.6月是因为Web的发展步伐很快。TBL认为Web逐渐结束了青春期而变得更加成熟和有用。
• TBL被问及关于Web的技术还有哪些让他感到振奋，他只提到Google和采访他的这家公司所作的一些事情。

此外还谈到了域名注册的垄断（ICANN ownership）带来的政治和经济问题、知识产权对Web开放性的影响及W3C的对策问题、语义Web的发展和本体的应用问题等等，最后介绍了下个月22至26日将在英国爱丁堡召开的WWW大会的议题，其中大量涉及Web2.0的内容。

由于做课题，把”史前时期”（1999年）的一些元数据标准拿出来看看（中国地理信息元数据标准），感受到我们这些年在元数据认识上的进步。

1. 元数据是对于数据/信息资源/对象/实体的描述，早期常常把元数据组成的信息系统/数据库当成目的，而常常不自觉地忽略了元数据只是信息资源的一个指代物/投影这样的事实，因此在系统中常常把元数据和对象数据同等看待，或者由于没有对象数据而把元数据就直接作为实体对象，从而造成元素描述对象实际上不一致的情况，这个问题可以归结为元数据和实体之间的关系未作区分。
2. 早期的元数据标准对于一组元素描述一组实体（资源集合）还是一种实体，以及不同（有交叉）的元素集描述不同实体这类重要的区别也不关心，常常将各类元素平面地”堆放”在一起，这也是传统关系型数据库应用的一个常见问题。对多个实体的描述可以构成一个相关连的描述集合，可以作为一条”元数据记录”。这个问题可以归结为实体和实体之间的关系未作区分。
3. 元数据元素之间的关系在早期的元数据方案中是隐含在元素名称中的，或者人为地采用”复合实体”形式或其他形式进行分组。而引入了”资源-属性-属性值”三元组结构之后就可以清晰地、显式地定义，元素之间的关系很自然地建立起来。
4. <!–[if !supportLists]–>在早期的元数据方案中元素与子元素的关系无法表达，一般情况下是有了子元素就不要元素，或者元素与子元素并存，但并不建立联系。这样做弊端很多。

可以看出，元数据抽象模型可以解决上述绝大部分问题。

注：
“早期的元数据标准”参见：中国21世纪议程管理中心（蒋景曈）编 《中国地理信息元数据标准研究》 科学出版社 1999年 16开 252页 定价23元 ISBN7030074874 上图索书号P910/5621。该书介绍了《中国可持续发展信息共享元数据标准》，该标准主要参考了FGDC（Federal Geographical Data Committee）的CSDGM（空间地理元数据内容标准）和ISO15046-15《地理信息–元数据》，这两者是基本一致的。标准制定的目的是：提供中国可持续发展共享信息元数据的内容，包括可持续发展数据标识、内容、质量、状况及其它有关特征。可用于全面描述、数据集编目及信息交换网络服务。

从OCLC最近的一些项目可以看到他们把书目信息（结合FRBR）用到了极致，而且向与用户信息进行综合的方向发展。Leon最近提到我们实际上可以利用书目与读者流通信息进行”挖掘”的课题可以做很多。当然一谈到现实就让人犯怵：业务规范、数据质量、代码调试等等等等。只好进行”思想试验”了。

OCLC的Eric Childress在最近应Jane Greenberg之邀去UNC SILS（北卡大学）的一次讲座中(下载ppt)提到了OCLC正在进行的一批项目：

• Audience Level 利用FRBR化的WorldCat及预借信息(holdings—-应为”馆藏”。特别鸣谢：精灵)获得读者的”水平”信息（根据图书馆性质判断。似乎有点侵犯个人隐私的嫌疑，当然可能不记录具体读者的信息，目的只是为了判断资源的受众–Leon提醒：在WorldCat借阅信息中应该没有具体读者的信息）。
• FictionFinder 为WorldCat中的小说书提供一个方便的搜索界面。可能有一些基于内容的特殊功能，例如版本变化、改编情况、甚至人物关系、地点线索等等（瞎猜）。
• Dewey Browser 利用DDC分类法提供导航界面，这是很多人都想到的点子，但是做起来恐怕没有想象的那么容易。
• Live Search 综合了FRBR、WorldCat和DDC等工具的搜索界面，提供读者快速、一站式发现体验。
• FirstSearch WorldCat FRBR pilot (OCLC FirstSearch) 要把WorldCat整个变成支持FRBR搜索的数据库。好像OCLC早就在做了，但是要到今年年底才能提供，估计在数据方面有些难度。

看了综合前三个项目的Live Search界面演示我在想，这种信息资源的知识体系组织能够实现这么好的功能，固然不错，然而对于Web上的信息来说却是不可能做到的，因为这后面凝聚着太多的人工。Google等公司一直想利用一种架构体系和纯软件/自动的方法来实现知识的组织和整序功能，OCLC的这些做法是否具有普遍意义呢？可能像DC元数据一样，OCLC还会向语义Web输送很好的点子吧。但愿如此。

Google公布了它的数据交换协议：GData (Google Data APIs Protocol) ，为大家利用Google的数据，以及利用Google的服务进行Mashup又提供了一个开放的标准，同时也给各种标准的混战增添了更大的混乱。

当然最成功的标准应该是由应用来推动的，特别是由Google这种最成功的公司来推动，才能价值最大化。国家集体个人三得利。

GData综合了一些聚合服务的传统功能，例如请求一个Feed，插入一条记录（Entry，如一篇博客文章），查询一个字串，更新、删除一条记录，等等。Joe Gregorio将GData与Atom和RSS2.0进行了功能上的简单比较：

其中涉及一些相关概念有助于理解Gdata：
Atom Store
OpenSearch

update:24日看到未完成对GData的详细介绍。

Saul Weiner 汇总了一批组织得很好的Web2.0网站目录（A List of Web2.0 Lists），因为他的网站被屏蔽了，只好搬过来，推介一下。以下是他收集的列表（无特定次序）：

1. Web2.0 Innovation Map
2. Listable Web2.0 List
3. Web2.0 Directory
4. Buzzshout
5. The Techcrunch Index
6. Bob Stumple’s List 1 and 2
7. Web2.0 List
8. Programmable Web mashup matrix
9. Emily Chang
10. FreshArrival Archives
11. Museum of Modern Betas
12. Web2.0 SlideShow

另有两个”最佳Web2.0网站”的评选站点，很值得参考（倒序排列）：

1. SEOmoz’s web2.0 awards
2. Dion Hinchcliffe’s 2005 awards 1 and 2

Saul还会不断更新他的列表，所以如果要看最新的，还是想办法访问他的网站吧。
（本贴通过performancing上载）

update（060515）: Web 2.0分类网站大全：http://categoriz.com/

近来甚为懒惰，但是”读者”来信不能不回，可能是年纪一把了，比较好为人师。把具有普遍意义的想法贴出来，也算求证吧，哪位看不过眼可以留言。
问：……那么我想我也只能从一个小的学科分支领域出发，构建这么一个实验本体，然后在此基础上实现检索，您看我这个想法可行吗？不知道这个工作量会不会很大，很难以实现，而且小的实验本体有可能会影响其语义的正确理解，好象违背其初衷啊，您觉得呢？……

答：本体研究是近年来的热点，进展很快，成果很多。而且可以说将来互联网的许多应用都会有本体的影子，所以你选择这个题目，我认为是大有用处，大有文章可做的。

提供一个思路：早期数字图书馆界研究本体，曾根据FRBR提出过一个ABC本体（见Carl Lagoze等人的文章），并根据这个本体对图书馆的信息资源基于生命周期的模型进行管理，目前FRBR应用于书目数据之间的联系已经比较成熟，OCLC还提供相应算法（xISBN），您如果能利用这个本体开发一个书目数据的视图工具，或者结合分类主题词表转换的本体再辅之以学科导航视图展示，这就是一个很好的基于本体的书目系统，不光有理论内容，而且有实用价值。

佩服自己有那么好的想法，无偿提供给你啊！嘿嘿。

一个网友问了三个问题：

1）您觉得如何从中图法的角度去构建这个本体呢，这个本体构建要达到一个什么样的程度呢？

2）这个本体用在数字图书馆中查询检索中的效率能有所提高吗？我这个课题会不会太大了？

3）还有我现在也不太清楚国内关于这块的研究到了什么一个程度，我是不是在重复别人的工作？

由于时间关系，很随意地简答了一下，如果大家有评论可以留言：

1、就知识组织角度来说，本体与中图法的形式上的差别很大，应用环境与方法也可以说几乎完全不同，虽然可以借鉴，但是推荐的做法还是以本体为主，吸收中图法关于知识/学科分类的思想。把一个分类法原原本本地翻译成一个本体，不是说做不到，而是没有必要。
传统知识组织体系的设计思路、功能、对象、用法与现在的本体是有很大区别的，有些概念没法翻译成本体，每个概念、概念间的关系都需要定义，许多模糊的概念关系需要明确，这不是个人的力量所能完成的，也不符合本体的目的。本体就是领域内使用，满足领域内知识的组织，只要在高层本体和顶层本体遵循一定的原则，将来能够组合/映射到一个更大的本体体系中去（起码采用的本体编码语言要一致，最好工具也一致）就可以了。
所以我的建议是以开发你想要的本体为目的，抽取各种分类法、分类主题词表中相关的部分，建立你的本体，而不要进行所谓转换。那样做吃力不讨好。

2、本体的作用与传统情报检索系统中分类法、主题法的作用有类似的地方，就是能对于信息体起到规范控制的作用，从而保证一定的查全率和查准率。当然本体还有许多其它作用，如知识关联作用、推理作用等等。但是对于提高查询效率我看不出会有什么大的作用，相反可能还会降低查询效率（当然你如果定义查询效率包括查全查准率的话，另当别论。在我看来查全率查准率是”查询效果”）。因为现在使用本体的基本上都采用基于XML的本体语言，越来越明显的趋势是采用OWL，OWL是基于RDF的，这方面的工具、算法等都还很初级，对于效率会有影响。据说Oracle最新版在内部支持RDF/RDFS了，也是刚刚开始。

3、国内有研究，但是研究不多，许多人一毕业就去了国外，所以国外搞语义Web的华人很多，有一些也蛮有名的。这方面研究我曾经看到别人搞过，但是搞的人不多，还是值得研究的，只是首先要占有文献，调研要周全一些。Kent大学曾蕾老师是这方面权威（搞NKOS），另外王军的报告和论文也算这方面的，应该多看看他们的东西。

今年清华将主办第一届亚洲语义万维网大会，值得关注。会议网站上也可以看到一些国内的牛人。另外这里经常会有一些讨论。

数字图书馆的语义互操作问题是要解决一个数字图书馆”读懂”另一个数字图书馆内容的问题。语义作为数字图书馆之间共享内容和进行交流的基本要求和最终目的，其互操作涉及到多个层次、多种复杂因素，是一件非常困难的工作。现有的技术对于具体的、个别的数字图书馆资源体系进行语义互操作开发，应该说是没有问题的，但是要建立普遍意义的语义互操作规范，就不是非常容易的了。总体说来，要实现数字图书馆的语义互操作，涉及三个方面内容：

1. <!–[if !supportLists]–>互操作协议（如Z39.50、SRU/SRW）、框架机制（如OpenURL，其本身并不是一个协议）或上述两者兼而有之（如OAI）；
2. <!–[if !supportLists]–>语义编码语言（如XML/XMLS、RDF/RDFS、OWL等）；
3. <!–[if !supportLists]–>语义描述规范（如DC、FGDC、IEEE-LOM）。

这三个方面可以构成一个近似的语义互操作空间，如图所示。

对于实现语义互操作来说，语义描述规范、形式编码语言和互操作协议三者缺一不可。

语义描述规范（z轴）是对数字图书馆内的数字对象、集合对象的语义、结构、服务、模型等各方面的描述规范，许多规范兼有语义、语法、结构描述的功能。对于信息资源及其集合不同的抽象程度、或者关注不同的方面，就可能有不同的描述规范。一般可以把这些规范分为与数字对象一定数据格式（微观数据结构）有关的数字对象规范、与资源集合和服务有关的资源集合描述规范（通常包括资源内容描述、服务描述和代理agent描述三个方面）和与知识/资源组织体系有关的规范（如分类法、主题法、各类词表等规范或半规范的主题框架Scheme）。坐标轴的方向表示了语义描述的兼容性、丰富性和适用性的增加，但同时语义描述的严格性、规范性程度和深度在减少。

形式编码语言（y轴）是语义描述规范为计算机所”理解”和处理的基础。目前各类语言大都基于XML，但是XML只是提供了一种结构化的形式和手段，并不能满足各类领域应用形形色色的编码要求，也不能保证所编码的信息内容在结构或语义上的互操作，而且基于XML的不同功能的编码语言还在不断产生。因此会有y轴上众多的编码语言，其中大多数是与语义的编码直接有关的。坐标的方向表示知识表示能力和语义的丰富程度的提高，同时规范化、形式化的要求也随之提高，数字图书馆支持的难度也随之增大。

互操作协议（x轴）是对于数字图书馆互操作（跨库检索、元搜索等）具体实现所需要用到的协议或者体系框架，目前互联网的绝大多数应用协议都可以用来传达语义信息，但是高层互操作协议一般对语义信息的编码进行了具体的规定，所以特别适合进行语义互操作。这些协议中的高层协议建立在下一层协议基础之上，其相互之间也有着复杂的关系，适合不同的软件和网络系统架构。坐标轴的方向表示互操作层次的提高，开放性的提高，或者松散耦合程度的增加等等。

具体数字图书馆的语义互操作能力体现在三者构成的坐标空间中，当然对于具体应用来说，其语义互操作性并不能以一个点来描述，可能是一组点甚至一个空间。

需要说明的是，该示意图只反映了对语义互操作空间的一种认识，并不具有绝对的意义。三个坐标轴上的许多规范由于是历史上逐步建立起来的，并不是在统一的模型和认识框架中形成，协议与编码、语义与形式的分离是计算机发展到一定阶段之后的产物，因而有些内容不能严格地属于某个坐标轴（例如CORBA并非严格意义上的一个协议，而是一套分布式架构规范），有许多遗漏（只列举了具有代表性的内容，例如有了CORBA就没有列举COM/DCOM；如Web服务等一类”复合型”的互操作框架也没有列入，而将其组成部分：SOAP/WSDL/UDDI分别列入了不同坐标轴）。各类规范之间的界限也并不是十分清楚，常有包容、相交的关系（多数后来的协议都是建立在HTTP基础之上的），或者找不到对应的规范形式（例如CORBA就没有对应的编码或者语义格式），或者只能”部分借用”（本来并非用于互操作目的）。例如许多语义规范并不能以某种形式化方式来表达，某些形式化方式也不被一些互操作协议所支持，这样的话”互操作空间”中就不存在某些交点。z轴上（语义描述规范）MARC本身不仅仅是元数据语义规范，它同时规定了形式，当然这种形式可以转换成XML或其他表达，这样的话我们把MARC还是看成一个语义规范。

x轴和y轴构成的平面说明不同的通信协议可以支持不同的编码方式，从而可以具有相应的互操作能力；x轴和z轴构成的平面说明一定的互操作协议需要携带一定的语义内容（通常必须经过编码）才能实现语义互操作的功能；y轴和z轴构成了对于语义进行形式化编码的空间，也就是对于语义进行标准化、规范化的内容。

一般的互操作问题只需要关注由x轴（互操作协议）和y轴（形式编码语言）构成的平面，缺省地假设语义问题都包含在编码中了，特别是一些特别适用于语义描述的编码，如RDF/RDFS、OWL等，他们或许会把MARC、XTM等语义元数据格式作为一种编码语言放到y轴上。然而单独列出”语义描述规范”的z轴，有利于我们将语义看成是独立的功能，需要在体系设计和系统实现中加以单独考虑，使其独立于应用、独立于编码、独立于具体的协议实现，这样的话语义互操作就具有了独立的意义，数字图书馆的语义层就得以创建和立足。

本章主要探讨x-z平面所构成的语义规范如何建立一定的体系架构、并依靠一系列通信协议实现应用中动态转换、映射等互操作功能，以及y-z平面构成的静态的数字图书馆语义描述的形式化规范，前者缺了后者，就没有了基于语义的跨系统共享或检索，后者缺了前者，也无法实现动态的、跨网络的服务。本研究希望通过这两个方面的探讨，初步建立起数字图书馆语义互操作的模型和架构。x-y平面构成的编码语言之间的互操作是近年来的一个热点研究领域，各类模式的互操作算法汗牛充栋，但是如果不涉及语义信息的描述、整合或互操作，则不属于本研究的讨论范围。

问：您好，我正在做论文关于元数据语义互操作的研究，想从语言学的角度对一些元数据体系的元素进行分析，试图找出定义元素时的缺陷，提出定义元素规则，设定命名原则，提出受控定义的词表。非常希望您对此提意见或建议。……

答：以下是我的理解，不一定正确，供参考。
语言学角度研究语义和语义Web的语义是不一样的，是不同层面的语义。当然也有一定的联系。所以我认为从语言学的角度寻求元数据设计和应用的根据是要走入死胡同的。计算机对于语义的研究只需要保证机器认为的”语义”的一致性就可以了，这个语义是编码的语义，至于人是不是能够正确接收，可以不管。而且构建语义Web的本体可以认为是领域本体，不是语言学或早期人工智能所追求的那种放之四海而皆准的绝对本体。

我的论文中有一段相关内容：

语义也是语言研究避免不了的问题。谁也不可能避开语义而探讨语言的理解，因为语言作为一种工具其最终目的就是为了人的理解，现在又扩大到机器”理解”。所需理解的内容就是语义，而不是语言符号及其组合。语义是获取知识的第一扇大门，如果说符号/数据是语义的载体，那么语义就是知识的载体，其转化机理目前还不得而知。语义的传播和吸收的多样性、多义性和随机性当然也创造了许多”知识”和”文化”，相声就可以看成是玩弄语义的一类技术，使人类的交流如此人文，如此丰富多彩。然而这其中存在的”歧义”和语义的不可控性正是机器之间的语义传递所要避免的。

语言学大师乔姆斯基一直反对基于逻辑传统的语义学研究，他认为这种研究通过一个模式，就给某种语言的任意一个句子指定一个涉及事情的可能状态的真值，是不足信的；人们会像看待句法学和音位学的结构成分那样去看待语义学模式里的结构成分，鉴于可能世界怎样在人的大脑里反映出来尚不可知，或者说，人们还不清楚在作判断时是怎样利用可能世界来实现思维，乔姆斯基的结论是：模式化-理论化的可能世界语义学不太可能取得成功，必须排除在语言学理论的组成部分之外。

然而对于计算机领域来说，人们长期以来一直在一些相对封闭的体系中进行语义学研究，或者无意识地解决了一些语义表示、匹配、编码等语义学问题。这些问题绕开了乔姆斯基所担心的人的认知问题，当然是否在乔氏眼里称得上”语义学”还是问题，但强调应用性是计算机科学的重要特征之一。

在计算机领域的应用中，语义通常是指用户对于那些用来描述现实世界的计算机表示的可能解释，即用户用来联系计算机表示和现实世界的途径。数据库表中的属性和关系都可以看作数据的语义信息。当然，语义并不是这么简单，它代表的关系更为复杂，超过了关系型数据库建模所能表达的范围，在数据库这样一种封闭的体系中语义虽然没有显式定义，但是其保存和传递是得到保证的，问题是不同数据库之间语义的共享就不是具体的数据库应用本身所能解决的了。

人类的心智如何赋予符号体系以”语义”，这是一个哲学范畴的问题，不是计算机科学所能解决的。然而正如通信理论将信息抽象为不确定性的度量一样，如果把”语义”问题抽象为计算机在对信息的传播、处理过程中对语义的保持和约束，使其获得”外在的”、”显性的”独立性，并依托一种机制实现其功能，而忽略人在接收信息时的对于语义理解的不确定性，即保证语义的传播过程的完整和准确，应该也是很有意义的。特别是对于”数字图书馆”这样一个确定的应用领域、具有基本明确的抽象模型、以”语义”信息的存储、传播和利用作为其存在目的的体系来说。这样的形式化的”语义”可以在数字图书馆中连同”语境”一起保存，甚至可以利用诸如本体技术，将”语境”信息也编码化，使其可以得到传递。这样就显著有别于”自然语言处理”对语义的前提假设，自然语言处理对语义的解释是：每个词的意义是什么，词的意义如何结合成句子的意义。希望找到”独立于语境的意义”，而我们强调语境对于语义的巨大作用，另外可以看到，自然语言处理与数字图书馆对于语义的研究，前者微观，后者宏观，前者强调揭示语言的语义规律，后者强调保持语义在交流过程中的可传播性，具有很大的不同。当然在对于语义的形式化和符号化表示方面，后者可以借鉴前者的很多成果。

SDARTS：SDLIP+STARTS SDARTS协议是由STARTS和SDLIP两个协议相互补充合并而成的一个互操作协议，是哥伦比亚大学承担的数字图书馆先导研究计划第二期项目中的内容<!–[if !supportFootnotes]–>*。SDLIP本身可以看成是START的一个特例，SDARTS又可以看作SDLIP实现的一个实例） SDARTS充分利用了STARTS和SDLIP在互操作方面的优势和可取之处，同时对于元搜索支持的元数据形式进行了定义，例如Dublin Core、Z39.50 Bib-1属性集、GILS Z39.50profile等。SDARTS项目对STARTS XML进行了标准化，创建了一个体系结构，将LSP分为两块：一部分是无需改变的前端，只需处理一种XML格式，另一部分是抽象的后端，对特定的底层数据集类型是可执行的。由此，其它具体的应用只需改写后端执行程序，为开发一套SDK专用来制作SDARTS封装器，通过提供标准的开发包和工具包而简化开发过程。SDARTS是这三个协议中最为接近实用的一个，至今在哥伦比亚大学的网站上还有一个支持OAI的版本可供下载。 <!–[endif]–>

*参见：Noah Green, Panagiotis G. Ipeirotis, Luis Gravano, SDLIP + STARTS = SDARTS a Protocol and Toolkit for Metasearching http://citeseer.ist.psu.edu/green01sdlip.html

SDLIP：简单数字图书馆互操作协议 SDLIP是一种基于HTTP或者CORBA的互操作架构<!–[if !supportFootnotes]–>*。它规定了三类基本接口：

*http://dbpubs.stanford.edu:8091/~testbed/doc2/SDLIP/

STARTS：因特网检索查询斯坦福协定 STARTS协议（Stanford Agreement for Internet Retrieval and Search）是斯坦福大学在其主持的数字图书馆项目Infobus中提出的一种”分布式异构资源检索”的互操作协议，受z39.50影响很大，于1996年推出1.0版本， 1999年康奈尔大学在其数字图书馆试验项目中利用CORBA作为传输层实现了这个协议。目前的版本是2.0*。 STARTS没有规定底层传输协议的具体实现方式，仅作为一个元搜索的架构，考虑了对于一组资源库，如果发出一个查询请求，该元搜索能够：

1. <!–[if !supportLists]–>找到合适的实施查询的资源库；
2. <!–[if !supportLists]–>针对不同的资源库进行查询；
3. <!–[if !supportLists]–>合并检索结果。

因此其希望解决如下问题：

• <!–[if !supportLists]–>无一致查询语言
• <!–[if !supportLists]–>难以合并结果集
• <!–[if !supportLists]–>难以获得元数据信息

解决方案是：

• <!–[if !supportLists]–>提供一个中间的Broker
• 或提出一套体系架构

Z39.50在Web时代的发展

Z39.50协议研发于Web技术出现之前，信息技术特别是网络技术在该协议推广应用的同时有了很大的进步，浏览器/服务器的架构迅速得到普及，客户机/服务器结构已不能满足最终用户的需要，于是许多Z39.50的应用都建立了浏览器/Web服务器/应用服务器三层架构，Web服务器通过CGI与Z39.50的客户端进行通信，再通过Z39.50服务器实现互操作。Z39.50可能还将跨越各个Web服务器，才能与世界各地的数据库应用服务器通信。

我们知道本来Z39.50协议就是为了打破异构数据库应用的封闭性，实现互操作的分布式检索。上述这种三层架构的组合在体系结构上和效率上都是非常不合理的。自2001年Z39.50准备推出第四版开始，就一直在研究和考虑这个问题，希望在体系架构上对Z39.50有一个彻底的改变，目前已经有了一些初步成果。

被称作ZING（Z39.50-International: Next Generation）的”下一代Z39.50协议”目前的版本是1.0，包括SRW/SRU、CQL、ZOOM、ez3959和ZeeRex五个部分。一方面可以看成是Z39.50各种功能在新的网络协议和应用模式下的拆解，另一方面是一种简化，许多相应的功能并没有Z39.50中所规定的那么完整、全面，其中一些只是为了实现新技术与老的协议的”兼容”而设立。

SRW/SRU：SRW（Search/Retrieve for the Web）和SRU（Search/Retrieve URL Service）

这两者是针对Web的信息检索协议，利用Web服务的架构，实现了Z39.50的一些基本服务。是ZING的核心功能。SRW使用HTTP与SOAP的无状态通信，采用XML作为信息传输编码，也可以单纯使用URL传递查询请求，用WSDL来定义Z39.50传输的格式信息，检索结果也以XML格式输出。而SRU只能通过URL参数方式提交检索请求，不支持完整的SOAP消息包（指支持SOAP消息报中的内容序列）。

SRW/SRU支持网络上现存的多种检索方式，这是其与Z39.50最大的不同之处。各种不同的检索服务都可以采取模块化方式组合调用，共同返回结果，而不像Z39.50一样对于规定了单一的检索方式。例如可以采用SRW/SRU将Google开放的检索API和A9开放的检索API进行整合，就是一种典型的Mashup，当然这样的整合也可以不采用SRW/SRU进行，但是这样做能够保证与其他任何支持SRW/SRU的系统（数字图书馆）进行高层互操作。这样使这个协议就具有了开放性，从而成为解决系统互操作问题的强大工具。

CQL：Common Query Language通用查询语言

CQL是一种类似于SQL，但远比SQL简单的查询语言，既有简单性，又能够混合指令与参数，并结合Z39.50 type-1的丰富性。目前的CQL支持布尔操作、混合检索点和检索词、支持指定元数据标签、支持结果及查询、支持服务器自动确定检索对象、支持多种匹配方式（精确匹配、数字比较、词根检索、盥洗次检索、模糊检索、语音检索等），可满足绝大多数简单查询的需要。XCQL指的是以XML方式编码查询提问语句的格式。

ZOOM：Z39.50 Object-Orientation Model Z39.50面向对象模型

ZOOM是一组符合Z39.50的面向对象的API结构，可以做为建立Z39.50客户端或SRW/SRU应用的起点和基础工具。

ez3950：Simple Implementation of Z39.50 over SOAP using XML Encoding Rule (XER)

ez3950是一个应用XER（XML Encoding Rule）和SOAP协议实现简单的Z39.50协议应用的机制和方法。也就是利用XER支持到ASN.1标准的动态转换，而不用修改Z39.50对后者的支持。

ZeeRex：

针对Z39.50的解释（Explain）功能的XML版本，反映SRW服务器组成和提供的功能信息，记录了数据库、检索点（Index）、数据记录格式以及客户段能够采用的参数说明信息等等，类似于一个服务注册体系中需要登记的信息。

Z39.50是严格基于ISO的OSI（开放系统互联）参考模型的应用层协议，是一个美国国家标准，其全称是American National Standard Information Retrieval Application Service Definition and Protocol Specification for Open System Interconnection。国际标准化组织也有一个类似的标准：ISO10162/10163。

提出Z39.50的起因是为了在美国国会图书馆、OCLC、美国研究图书馆集团（RLG）等机构之间交换数据。其第一版于1988年推出，并于1992年和1995年推出了第二版和第三版，内容有了很大的充实，第三版还于1998年成为ISO23950国际标准。2001年和2003年又修订了两个版本，目前最新的是2003年的第五版：Z39.50:2003。同时Z39.50一直在进行一些试验性计划，把Z39.50的标准进行拆分，提出”下一代Z30.50″的新框架。

Z39.50的目的是为了信息系统的开放互联，由于各信息系统分别采用各自的数据库软件，数据的描述格式、访问方式等都各不相同，必须为各自数据库系统建立一个抽象、通用的用户视图，将各个系统的具体实现映射到抽象模型上，才能使不同的系统在一个相互理解的、标准的通信平台上进行交互，满足互操作的需要。

在当时的技术环境下，Z39.50采用了客户机/服务器的灵活架构，主要定义了所提供的服务和应用层数据包格式两方面的内容。信息服务包括11项内容：初始化、搜索、获取、删除结果集、访问控制、记帐、排序、浏览、解释（获得细节）、扩展服务（如周期搜索计划）、终止等。

由于Z39.50非常详细而烦琐，在应用中通常无需全面实现其个方面的功能，因此在标准中提出通过Profile形式，确立应用中对协议的实现细节的具体描述。例如Z39.50认可的Profile有Bath、GILS、WAIS、ATS-1等。

Z39.50对于互操作最大的价值在于实现了信息查询和提取过程的标准化，虽然采用的方式是一种比较封闭的做法，这也是与当时的技术环境有关。协议规定了完善的语法（七种查询条件表达格式），以及所支持的信息资源的元数据格式（15种属性集），例如常用的Bib-1、Exp-1、Ext-1、GILS-1、STAS等。每个属性集由一套属性类型+属性组成。属性集的规定是使用Z39.50协议获得不同资源库彼此的元数据信息、实现语义互操作的基础。

又要2.0布道了,上网收集资料,看到以撒的天空一篇好玩的咚咚,翻译一下: The Real Definition of “Web 2.0″

数字图书馆的建设目标是向用户提供围绕信息资源的各种服务，实现语义互操作的主要困难是不同的数字图书馆采用不同的硬件环境、编程语言、网络环境、数据格式等，因此提供一个规范信息描述和信息解释的系统环境作为一个统一框架，必须以适当的方法管理和使用不同元数据和本体（不论是不是规范的或有意识）建立的语义系统，必须建立或对已有系统抽象出一个统一的、能够进行互操作的语义层。

为此本文从以下三个方面入手建立数字图书馆的语义架构：

<!–[endif]–>

<!–[if !supportLists]–>1. <!–[endif]–>基于本体的元数据的规范描述体系；
2. 自动的基于Web服务的元数据映射、转换服务；
<!–[endif]–>3. 支持语义服务的数字图书馆模型设计。

实际操作可以遵循两种具体的实现路径：自顶向下和自底向上法。

自顶向下的方法意味着从理论到实际：

<!–[if !supportLists]–>1、 <!–[endif]–>需求分析，选择环境、平台、技术标准规范。如与谁互操作，如何互操作；
<!–[endif]–>2、 建立领域本体；
<!–[endif]–>3、 建立元数据方案（属性描述）；
<!–[endif]–>4、 建立规范体系；
<!–[endif]–>5、 编码；
<!–[endif]–>6、 系统设计；
<!–[endif]–>7、 实现与现有系统/语义Web的互操作。

自底向上的方法意味着在现有资源库的基础上抽象出语义架构和语义视图，以达成互操作：

<!–[if !supportLists]–>1、 <!–[endif]–><!–[if !supportLists]–>现有系统分析；
<!–[endif]–>2、 互操作需求分析；
<!–[endif]–>3、 选择方式：federation, harvesting, gathering；
<!–[endif]–>4、 选择方式：annotation, abstraction；
<!–[endif]–>5、 建立本体/元数据规范；
<!–[endif]–>6、 用本体/元数据规范对资源进行抽象，编码；
<!–[endif]–>7、 互操作实现。

目前大多数研究（特别是Semantic Web的研究） 都把语义互操作归结为实现本体之间联系的研究，对于数字图书馆来说这是不够的。当然术语一致性对DL来说具有同样的重要性。可以通过以下架构实现DL的术语规范：

1. <!–[endif]–>定义URI，实现术语的唯一性；
2. <!–[endif]–>允许术语的不同定义：概念的交叉、冗余及模糊性；
3. <!–[endif]–>实现术语间关系的规范描述；
4. <!–[endif]–>通过本体及本体映射，实现术语的”语境”联系；
5. <!–[endif]–>提供相应的术语服务，也即”权威控制服务”。（哪些服务?）