Delight in Thinking

    技术与人文之间的争论其实很无聊，因为道理非常明白，不应该有所争论的。比如商学研究领域，电子商务的出现受到商学研究的热烈追捧，没见什么人说服务是第一位的而排斥电子商务。技术的发展延伸了服务，这是不用讨论的，电子商务的成功说明了一个非常简单的道理，那就是在网络时代，任何服务只能架构在强有力的技术支撑之上。图书馆服务当然也不可能是例外。而恰恰很多图书馆界的“聪明人”看不到这些，不知道这是“聪明人”的悲哀还是图书馆界的悲哀。有些人还振振有词地打出“图书馆是制度安排”这样的口号，那我要问，什么社会机构不是制度安排？如果一定要说图书馆是什么安排，那么毫无疑问，图书馆是一种技术安排。
    有些人可能并不反对技术，内心甚至也认同技术的重要性，他们只是反对“技术救图”这个说法，他们担心自己被排斥在技术圈子之外，无法参与轰轰烈烈的救图事业，这样的担心非常可爱，但是没有必要。技术救图不是几个技术专家的事情，而是全体图书馆员的事情。厦门大学有个非常了不起的制度创新–“饭团”。“饭团”的起因我不清楚，但是这个“饭团”集中全馆所有热爱关心图书馆发展的年轻人，不论他们是在什么岗位，什么专业背景，IT专家也好，编目专家也好，流通部的图书馆助理也好，都可以参加这个“饭团”，“饭团”成为一个跨部门、跨专业，以技术为核心，涉及整个图书馆业务领域的技术创新小组，群策群力一起为图书馆技术的发展添砖加瓦，成为图书馆技术创新的发动机、点子库，我想，这应该是厦门大学图书馆在技术发展领域走在业界前列的重要原因。饭团的机制不仅在厦门大学图书馆有，而且我们也可以在上海图书馆、北京大学图书馆、上海交通大学图书馆等大型图书馆里看到饭团的影子，这些图书馆都是技术发展的佼佼者。饭团是个伟大的机制创新，在这个机制下，每一个图书馆人都可以投入到图书馆技术创新与发展的洪流中，那是多么激动人心？那些反对技术救图的人们，为什么不甩掉包袱，投入到这样的洪流中去？
    技术救图是全体图书馆员的事情，不只是技术专家们的事情，但是技术专家在技术救图中毫无疑问地担当了重要角色。然而，图书馆技术专家却被图书馆界舆论边缘化了，当全世界图书馆技术专家享受着高工资高地位时，我们的技术专家却被边缘化，这是不正常的。记得和“技术救图”提出者讨论提出这个口号的缘由时，他深深地为图书馆技术部门的边缘化感到担忧，技术部门集中了大量的优秀人才，担负着举足轻重的职责，他们应该得到更多的关注和重视，发挥更大的作用。我深信他的看法是对的，是为图书馆未来的发展深谋远虑的。这也是我不遗余力地为“技术救图”摇旗呐喊的原因。
    其实，像我这样的普通图书馆员，无非只能在边上鼓鼓掌喊喊加油而已，有时喊破了嗓子，被你一句带套全部抵消。我能做的无非是做个跳梁小丑驳大家一笑而已，而您却可以有更大的作为，这是为什么我突然想给您写这封信。
    程教授，你们这一代图书馆学家是值得尊重的，因为你们的摇旗呐喊和艰苦实践，我们的图书馆从一个衙门为导向的事务性机构变成了一个服务为导向的社会性机构，这是30多年来，图书馆事业发生的革命性飞跃，您、老槐等等这一代承先启后的图书馆学家中的佼佼者都是我们崇拜的偶像。服务的确是图书馆赖以生存并持续发展的基础，我们深深认同您的服务理念，但是，服务和技术并不矛盾，强调服务并不是要以排斥技术为代价，在现代技术高速发展的今天，服务和技术其实是密不可分的，技术即服务、服务即技术，我们无法分别彼此。技术的发展总是出乎人的想象，也出乎人的情感，我知道您对书卷有着深深的眷恋，那书香会让您如痴如醉，但是技术在变化、时代也在变化，我们的新一代用户眷恋的不再是书卷，让他们如痴如醉的也不再是书香，而是鼠标的喀喀声。我们怎么办？我们总不能把孔老二用过的竹简摊在桌上，逼着年轻人读罢，我们也不能像治疗网瘾那样，电击不读书的读者。我们唯一能做的就是改变我们的服务模式，把我们的服务融入到他们熟悉的环境中去，这就是技术救图的基本设想。程教授，您作为一位图书馆学教授和一所大型学术图书馆的馆长，应该能够引起共鸣的。
    程教授，您可能看不起技术酒徒，甚至您可能看不起现代技术，但生活在这样一个技术世界里，您可能无法回避技术，既然无法回避技术，为什么不为技术鼓掌加油？也许您换个角度换个立场，对技术发展贡献会是巨大的。
    技术探索是一个痛苦的过程、寂寞的过程也是承受巨大压力的过程，技术酒徒不仅需要有聪明才智，更具要有坚强的毅力。在我心目中，这些坚强的图书馆技术探索者是英雄。我无法成为他们的一员，但希望能够为他们鼓掌欢呼，也恳请竹帛斋主加入到我们拉拉队里来，我们一起为技术酒徒们加油鼓劲。好么？

         这个题目很豪华，囊括了目前信息技术领域许多的热点词汇，从Web2.0到云计算，这些鲜亮词汇构成了一幅Web世界从过去走向未来的线路图。

         网络世界的生命周期大约是以十年为一个阶段，从第一代Web到Web2.0大约经历了10年左右，这10年中，Web解决了人与网络的交互问题，即从Web1.0仅仅提供用户阅读网络信息的便利发展到了Web2.0为用户提供了交互通道，从此，Web 不仅仅是一个媒体，而是一个可以相互沟通的信息交换平台。在Web2.0环境下，用户不只是Web的阅读者，而且也是Web内容的提供者和参与者, 今天，Web2.0基本已经成熟而成为Web的主流。大量的Web2.0站点充斥网络，并培育了大量的用户，可以说，Web2.的兴起真正培育了一个虚拟的网络社会。

        Web2.0的一个主要特征是参与，即Web用户可以参与Web的内容建设。这是一个表层的特征，在这个特征背后是技术构架的变迁，Web1.0主要是有网页构成，而到了Web2.0, 网页已经不再是Web的基础，而是应用系统，尤其是被称之为内容管理系统（CMS）的Web应用系统，Web1.0到Web2.0的发展是从Web Page 到Web Application的发展变迁。

        这种技术结构的变迁改变了网络的基本属性，Web不再是一个个孤立的站点通过网络联系起来，而是Web应用的各种整合，Web变成了通过功能和内容整合起来的一个整体，变成了一个大系统。为了实现这样的整合，需要解决在Web环境下系统之间的相互沟通，尤其是功能和数据的重用问题，因此催生了Web Service架构，这种面向服务的构架成为Web2.0的标志性架构。所以，从技术架构角度看，Web2.0的特征就是Web Service即网络服务。

        Web作为一个分布式的大系统，不仅需要开放式的Web Application services(Web 应用服务)，还需要被结构化描述的数据。只有通过结构化描述的数据，才能被应用系统所理解，换言之，一个有效的分布式的网络应用系统需要有机器能理解的数据。如果说 Web2.0是建筑在开放式的服务构架上，那么新一代网络将在此基础上构建一个机器能理解的结构化的和相互关联着的数据环境，一旦这个数据环境建立起来，那么Web将进入一个新时代，这个新的Web环境我们可以称之为Web3.0。

        Web3.0将要解决的是一个数据的表述，使得机器能够理解数据的结构信息，这个结构信息被称之为数据的语义信息，这就是语义网络需要解决的核心问题，所以语义网可以看成是Web3.0的起点。语义网经历了一个从概念到现实的发展过程，其技术架构也越来越清晰，那就是备受关注的关联数据（Linked Data）。关联数据有两个基本点，那就是描述和连接。描述和链接都是为机器服务的，通过描述可以实现机器自动发现和确认，链接可以支持机器自动链接。

        我们再回过头来看web1.0，1.0条件下，浏览器从服务器那里获得信息，直接显示在屏幕上，并不知道信息的含义，网页通过超链接相互联结起来，但需要人工点击触发，2.0可以通过机器来自动聚合各种信息，而到了3.0，网络在数据层就建立了链接机制，数据的结构信息被很好地描述着，并通过URI来确保机器能够自动链接各种数据，实现了信息聚合的智能化自动化。

        那么，云计算不就顺理成章了么？

Linked data 可以说是新一代语义互联网的基础，具有非常广泛的应用前景。不久前W3C宣布，SKOS将全面 Linked Data化. (Needle, 2009)这对于图书馆界来说意义深远。SKOS的linked data化应该是得益于图书馆界，美国国会图书馆将国会标题表（Library of Congress Subject Headings）全部Linked Data化，成为Linked Data应用的成功范例，推动了Linked Data走向实用。这又可以说是图书馆界对互联网的发展做出贡献的实例。

Linked Data的基础是RDF和http协议，换言之，Linked Data是通过Http来传递RDF数据，而这个RDF数据是一个遵循特殊规则的语义数据，这个规则就是任何资源都用URI 来表征。所以URI\RDF\HHTP构成了Linked Data 的三个基石。任何Linked Data 的应用都围绕着这三个方面展开的。如：

• 如何构建资源的 URI?
• 如何建立RDF 资源？
• 如何利用http 来传递RDF?
• 如何接受并解析RDF数据资源？ 等等。

Linked Data 的应用有两种基本模式：一种模式是浏览器/服务器模式，即人们通过浏览器来访问Linked Data; 另一种模式是客户端/服务器模式，这里的客户端主要是指应用系统，这个模式其实就是系统和系统之间的数据传递。无论何种模式，Linked Data都是通过Http来传递的。

Http 协议其实定义了两个过程，一个是请求，另一个是响应。以这两个过程为蓝图，我们可以模拟一个 Linked Data 传递过程。

• 客户端或浏览器发送一个RDF 文件请求给服务器，要求服务器返回一个 RDF 文件。发送这个请求很简单，你可以直接输入一个rdf文件后缀，如http://www.cloudlibrary.info/rainzenfoaf.rdf 就是一个简单的rdf 请求。当然，这个请求是很弱的，文件用rdf 作后缀不一定就是RDF 格式的文件，反过来，RDF格式的文件的后缀也有可能不是 rdf。所以用文件后缀来传递RDF请求不很可靠。我们需要的是一种强制性的非常明确的RDF 请求方式，这个请求只能通过系统（如浏览器）而不是人工来发出。现在通用的浏览器无法发出这样的请求，为了应用Linked Data我们需要能够发出RDF 请求的浏览器。
• 当服务器接收到一个RDF请求后，需要返回一个 RDF文件，并告知客户端这是一个RDF文件。这个过程被称之为content negotiation。 为了实现这个基于RDF 的content negotiation，这就要设定MIMEType, 定义一个RDF类型。2004年一个关于RDF的content type： Application/RDF+XML被注册。 对Linked Data 而言，content negotiation是非常重要的，如果要发布Linked Data，需要服务器能够很好地实现content negotiation。
• 服务器送交一个响应个客户端，尤其是浏览器，那么如何来解析这个 RDF 文件？特别是在浏览器模式下，由于RDF 不是给人看的，而是给机器看的，如何将机器语言翻译成人能够读懂的表达方式？这又需要一种特别的浏览器来解析RDF。

从这个过程看，应用linked data需要:

• 一个能够发送 RDF 请求，并能够解析 RDF的浏览器，我们称之为RDF浏览器。 Keven 在其博客中介绍了很多RDF 浏览器或插件。 (Wei, 2009)
• 一个服务器能够返回RDF类型的服务器。幸运的是，我们常用的Apache开源http服务器:就是为数不多的能够很好实现content negotiation的服务器。

在利用Apache 发布Linked Data时，需要对Apache进行简单设置，需要增加一个关于RDF的content-type，方法是在 Apache的设置中，或在.htaccess中增加一个类型说明： AddType application/rdf+xml rdf 。这样Apache接收到RDF的请求时，就可以回送RDF类型消息。

但是，由于application/rdf+xml是新注册的，有些浏览器还不兼容，我发现一个现象，访问http://www.cloudlibrary.info/rdf/rainzenfoaf.rdf时，通过检查文件头的软件得知，服务器返回了一个application/rdf+xml的文件，但通过Firefox看文件信息，却被解释成text/html。看来firefox的默认content-type是text/html，而不认可application/rdf+xml类型，当接收到这个类型时，起用了默认值。

另一个有趣的现象是，Apache 的默认类型是text/plain，如果不设 RDF类型时，服务器无法确认RDF文件，从而启动默认值，把 RDF文件当成text/plain。返还的是文本文件信息，这时在浏览器上显示文本文件。那么，是不是必须增加application/rdf+xml这个类型呢？其实也是不一定的，上面已经说过，FireFox把application/rdf+xml解释成text/html， 那么我们添加一个类型： AddType text/html rdf 也行，或者直接将Apache的默认值设为text/html就行了。那么如何解释回送过来的是text/html信息，而浏览器却能解析成RDF呢？看来浏览器这端还需要一个判断，通过分析标记语言来判断是否是RDF文件。不过在系统与系统之间的通讯，我以为还是应该启用application/rdf+xml，这样更加可靠明确。

本文是和Keven讨论过程中形成的，感谢Keven对本文的贡献。

参考文献：

Needle, David. 2009. W3C’s New SKOS Standard Advances Linked Data. [联机] 2009年August月18日. [引用日期: 2009年August月27日.] http://www.internetnews.com/dev-news/article.php/3835176.

Wei, Liu keven. 2009. 关联数据浏览器. 数图研究笔记. [联机] 2009年August月26日. [引用日期: 2009年August月27日.] http://www.kevenlw.name/archives/1844.

背景链接

http://www.w3.org/Protocols/

http://www.iana.org/assignments/media-types/application/

图书馆学研究正在脱胎换骨，最近发表的FRSAD草稿又一次印证了这样的变化。和FRBR一样，FRSAD是一个概念模型，是用来表述人类认识世界的基本框架，和传统的图书馆学研究不同，FRSAD的研究方法采用了一种更为精确的表述结构，使得其研究成果更为容易地被解析、编码和处理。当人们讨论图书馆学精确化，FRSAD展示了一种可行的方法。

FRSAD的核心是用来表述我们的认识世界，FRSAD的草稿中解释其目的是为了给FRBR中的著作（work）的“关于”（aboutness）建立概念模型。当我们说“这本书是关于‘清末民初中国议会制度’的”，这句话的含义是什么？如何形式化地表达这句话的含义？这句话的逻辑结构是什么？FRSAD试图给出一种阐释方案。显然，FRSAD是和FRBR密切联系在一起的，她自己宣称是为FRBR的Group 3建模型， ((FRSAR), 2009)但我个人以为，FRSAD的意义不仅在于此，而更重要的是为更为广泛的认知世界建立描述模型，换句话说，是为整个“客观知识”世界建立模型。

正因为FRSAD 有意无意地在为客观知识建模型，那么FRSAD的工作起点是非常哲学化的，在很大程度上，FRSAD可以看成是一种认识论模型，如果追溯FRSAD的哲学根源，大概可以溯源到亚利斯多德时代的本体论。

FRSAD的核心是Thema-Nomen 模型，这个模型假设任何作品（work）[注] 都具有主题，主题被称之为Thema（希玛）, 任何希玛都可以每表达成Nomen（诺门）。 ((FRSAR), 2009)对应于作品（Work），希玛也是抽象的，而诺门是希玛的客观表达，即用各种语言、符号表达希玛。这个假设非常重要，这是任何主题的翻译、标引、规范控制的基础。举清末民初中国议会制度而言，关于这个主题可以被表达成中文主题词、也可以被表达成英语主题词，也可以被表达成中国图书馆分类号，也可以被表达成美国国会图书馆分类号。这么多表达根据我的理解都应该是属于诺门范畴，而希玛只有一个。由于希玛的存在，图书馆才可能用不同的标引系统来描述同一种文献，不同标引系统之间才可能相互映射起来。

Thema-Nomen模型的主要内容是阐述Thema和Nomen的属性和相互关系，其中界定Thema-momen之间的各种关系是模型的关键，这些关系包括

• 希玛和诺门之间的关系；
• 希玛和希玛之间的关系；
• 诺门与诺门之间的关系

FRSAD已经详细地界定了各种关系，详见原文。

在实际应用中，困难的是对希玛定义各种元类，你可以将这些元类定义成金木水火土，也可以利用阮冈那赞的分面分类法中的各个面。

FRASD是一个庞大的系统，不是一两句话能够说清楚地，也不是一两天能够完全理解的。以上的议论只是我的一些初步看法，不很严谨也可能是误解，权当抛砖引玉，更为详细的评论会在不久的将来发表在自己的新博客http://www.cloudlibrary.info上。

此外，FRASD项目组的主席是我们大家熟悉的曾蕾教授，所以读FRASD时我们会倍感亲切。

参考文献：

(FRSAR)Working Group on Functional Requirements for Subject Authority RecordsIFLA. 2009. Functional Requirements for Subject Authority Data (FRSAD) ：A Conceptual Model. Draft, 2009年. [引用日期: 2009年June月29th 日.] http://nkos.slis.kent.edu/FRSAR/report090623.pdf.