Delight in Thinking

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.