Delight in Thinking

L inked data可以說是新一代語義互聯網的基礎，具有非常廣泛的應用前景。 不久前W3C宣布，SKOS將全面Linked Data化. (Needle, 2009)這對於圖書館界來說意義深遠。 SKOS的linked data化應該是得益於圖書館界，美國國會圖書館將國會標題表（Library of Congress Subject Headings）全部Linked Data化，成為Linked Data應用的成功範例，推動了Linked Data走向實用。 這又可以說是圖書館界對互聯網的發展做出貢獻的實例。

L inked Data的基礎是RDF和http協議，換言之，Linked Data是通過Http來傳遞RDF數據，而這個RDF數據是一個遵循特殊規則的語義數據，這個規則就是任何資源都用URI來表徵。 所以URI\RDF\HHTP構成了Linked Data 的三個基石。 任何Linked Data 的應用都圍繞著這三個方面展開的。 如：

• 如何構建資源的URI?
• 如何建立RDF 資源？
• 如何利用http 來傳遞RDF?
• 如何接受並解析RDF數據資源？ 等等。

L inked Data的應用有兩種基本模式：一種模式是瀏覽器/服務器模式，即人們通過瀏覽器來訪問Linked Data;另一種模式是客戶端/服務器模式，這裡的客戶端主要是指應用系統，這個模式其實就是系統和系統之間的數據傳遞。 無論何種模式，Linked Data都是通過Http來傳遞的。

H ttp協議其實定義了兩個過程，一個是請求，另一個是響應。 以這兩個過程為藍圖，我們可以模擬一個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展示了一種可行的方法。

F RSAD的核心是用來表述我們的認識世界，FRSAD的草稿中解釋其目的是為了給FRBR中的著作（work）的“關於”（aboutness）建立概念模型。 當我們說“這本書是關於'清末民初中國議會制度'的”，這句話的含義是什麼？ 如何形式化地表達這句話的含義？ 這句話的邏輯結構是什麼？ FRSAD試圖給出一種闡釋方案。 顯然，FRSAD是和FRBR密切聯繫在一起的，她自己宣稱是為FRBR的Group 3建模型， ((FRSAR), 2009)但我個人以為，FRSAD的意義不僅在於此，而更重要的是為更為廣泛的認知世界建立描述模型，換句話說，是為整個“客觀知識”世界建立模型。

正因為FRSAD有意無意地在為客觀知識建模型，那麼FRSAD的工作起點是非常哲學化的，在很大程度上，FRSAD可以看成是一種認識論模型，如果追溯FRSAD的哲學根源，大概可以溯源到亞利斯多德時代的本體論。

F RSAD的核心是Thema-Nomen模型，這個模型假設任何作品（work）[注]都具有主題，主題被稱之為Thema（希瑪）,任何希瑪都可以每表達成Nomen（諾門）。 ((FRSAR), 2009)對應於作品（Work），希瑪也是抽象的，而諾門是希瑪的客觀表達，即用各種語言、符號表達希瑪。 這個假設非常重要，這是任何主題的翻譯、標引、規範控制的基礎。 舉清末民初中國議會制度而言，關於這個主題可以被表達成中文主題詞、也可以被表達成英語主題詞，也可以被表達成中國圖書館分類號，也可以被表達成美國國會圖書館分類號。 這麼多表達根據我的理解都應該是屬於諾門範疇，而希瑪只有一個。 由於希瑪的存在，圖書館才可能用不同的標引系統來描述同一種文獻，不同標引系統之間才可能相互映射起來。

T hema-Nomen模型的主要內容是闡述Thema和Nomen的屬性和相互關係，其中界定Thema-momen之間的各種關係是模型的關鍵，這些關係包括

• 希瑪和諾門之間的關係；
• 希瑪和希瑪之間的關係；
• 諾門與諾門之間的關係

F RSAD已經詳細地界定了各種關係，詳見原文。

在實際應用中，困難的是對希瑪定義各種元類，你可以將這些元類定義成金木水火土，也可以利用阮岡那讚的分面分類法中的各個面。

F RASD是一個龐大的系統，不是一兩句話能夠說清楚地，也不是一兩天能夠完全理解的。 以上的議論只是我的一些初步看法，不很嚴謹也可能是誤解，權當拋磚引玉，更為詳細的評論會在不久的將來發表在自己的新博客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.