關聯數據的消費技術及實現＊

□夏翠娟 劉煒

1 概述

Web上關聯數據的發布正呈井噴之勢，截至目前，最新版的DBPedia3.8已發布了377萬件事物（Thing）的數據，其中235萬基于知識本體組織，包括個人（Person）、地點（Place）、機構組織（Organization）、物種和疾病等實體（Entity），所使用的知識本體包含359個類、800個對象屬性、859個數據類型屬性、2347種本體映射，提供111種語言的本地化版本。Freebase則有2300余萬實體，而語義搜索引擎sameAs.org則抓取了4300萬實體，LOD項目中著名的關聯數據云已經包含了328個關聯數據集（Linked Data Sets），涵蓋了生物醫學、政府、圖書館、教育機構等多個領域。關聯數據已成為整個全球性數據空間不可或缺的一部分，更重要的是，關聯數據作為一種分布式環境下，基于語義關系的信息資源集成方式，使得Web上分布著飽含語義的、海量的、相互關聯的數據，這些數據如果得到充分利用，會產生難以估量的巨大價值。

如何利用Web上的關聯數據，需要對關聯數據的消費（Consuming）方式和技術有深入的了解。發布和消費是關聯數據相關技術的兩個方面，發布的目的即是為了消費，有的是在內部消費，用于資源管理、整序、發現和重用等，典型的例子如BBC的關聯數據應用［1］；有的是開放給整個互聯網進行消費，如DBPedia、Freebase等大型公共關聯數據集；有的同時兼具消費者和提供者雙重角色，如各種語義搜索引擎。關聯數據的消費技術主要涉及關聯數據的訪問、獲取、發現、查詢、交換、傳輸、處理和利用等消費過程中所相關的各類實現方式、技術標準及工具平臺。關聯數據的消費方式與數據源所提供的消費接口密切相關，目前關聯數據源大致可分為兩種：語義搜索引擎和關聯數據集。本文總結了關聯數據的消費技術及相關標準，對上述兩種關聯數據源所提供的消費接口進行了調研，通過幾個案例來說明關聯數據消費的實現途徑，既考慮到關聯數據消費方的技術需求，也為關聯數據的發布提供參考方案。

2 研究與應用現狀

對于關聯數據消費方式和技術的研究與應用主要是國外，國內更多的關注還在關聯數據的發布層面，在消費層面的關注較少，黃永文的《關聯數據驅動的Web應用研究》一文分析了國內外基于關聯數據的7種Web應用類型，最后從用戶界面和交互方面、關聯關系的有效性、數據融合和模式映射、關聯開放數據的許可4個方面討論了關聯數據應用面臨的挑戰［2］。白海燕的《關聯數據與DBPedia實例分析》一文中以DBPedia為例總結出關聯數據的三種Web獲取方式和建立自動關聯的兩類常見算法［3］。另外在2012年7月上海圖書館舉辦的“從文獻編目到知識編碼：關聯數據技術與應用”專題研討班上，林海青的《關聯書目數據：發布、查詢、消費及混搭》，對關聯數據消費技術如查詢和混搭做了普及性的報告［4］，夏翠娟的報告《關聯數據的實現技術及案例》對關聯數據消費的流程、技術、應用體系架構及相關工具平臺做了梳理和分析［5］。雖然關聯數據的消費在國內的研究層面引起了注意，但進行深入研究與利用的還很少見，較為有影響力的是南京大學Websoft研究團隊開發的語義搜索引擎Falcons，可以查詢對象、概念、知識本體和文檔。

在國外，從研究方面來看，2009年Tom Heath在其LinkedData：EvolvingtheWebintoaGlobal DataSpace一書中，系統地論述了關聯數據“消費”的概念、消費方式、構建關聯數據應用的技術和原則、在關聯數據消費過程中應解決的問題如數據質量等，書中用單獨一章來談關聯數據的消費，包括目前關聯數據消費的現狀、關聯數據應用的體系架構及其不同的模式、關聯數據混搭應用的開發、數據發布者和數據消費者以及第三方應該如何聯合起來以促進 “數據的網絡（Web of Data）”的一致性和整體性。在該書中，將關聯數據的消費方式分為通用的和領域的兩種，通用的消費方式包括瀏覽和檢索，即基于如Disco、Tabulator、Marbles等語義瀏覽器的瀏覽，和基于 SWSE、Swoogle［6，7］、Falcons、sig.ma等語義搜索引擎的檢索［8］。使用語義瀏覽器的關聯數據消費者一般是人而非機器，而語義搜索引擎則可同時對人和機器服務，大部分的語義搜索引擎都提供面向人的界面和面向機器的數據消費接口。領域的則根據不同的領域數據源所提供的消費方式而多種多樣，取決于數據源（包括關聯數據集和語義搜索引擎）提供何種消費接口。另一方面，自2010年起，關聯數據的消費（Consuming Linked Data，CoLD）作為國際語義網大會（ISWC）的一個專題會議，已連續舉行了兩屆，第三屆將在今年繼續舉行，在CoLD專題會上，與會者主要展示一些消費工具和平臺的原理、功能及使用方法，如Christian Bizer等的用于不同詞表映射的R2R框架、用于關聯關系發現的SILK框架、用于關聯數據整合的LDIF框架等；還有應用案例的演示、經驗的分享，如探討聯合消費多個關聯數據集的技術方案。在2011年的CoLD會上，還提到了封閉（Closed）關聯數據和綠色（Green）的關聯數據的概念。

從技術標準和工具平臺方面來看，關聯數據作為語義網的一種輕量級的實現方式，早期的語義網研究成果如RDF數據模型、RDF查詢語言Sparql、元數據（Metadata）、知識本體（Ontology）的相關理論和技術是它的基礎，致力于語義網研究和應用推廣的機構如 W3C、DERI、LATC、還有許多大學研究機構等，不僅參與制定和維護如RDF、Sparql語言、Sparql協議、OWL本體語言等基礎的技術標準，近年來基于這些技術標準不斷地開發出各種工具和平臺致力于關聯數據的發布、消費和利用，就消費來說，從語義瀏覽器如Tabulator、Disco，到語義爬蟲和語義搜索引擎如 Sig.ma、SWSE、Swoogle、Falcons，到關聯發現整合平臺如SILK、LIMES、LDIF等，這些工具絕大部分是開源的，依據一定的開源協議提供免費下載。

從應用方面來看，Web上公開的大型關聯數據集如DBPedia、Freebase由于其海量的數據、多樣的消費接口，已成為全球性的數據消費中心，在各個領域得到利用，尤其是政府信息公開、地理信息、生命科學、圖書館檔案館博物館等，不僅作為數據的提供方，更作為數據的消費方，消費來自DBPedia、Freebase和其他領域性關聯數據集中的數據，如西班牙國家圖書館的關聯書目數據，就用owl：sameAs和rdfs：seeAlso關聯到DBPedia和美國國會圖書館的虛擬國際規范檔（Viaf）。關聯數據的消費也滲入移動領域，一個典型的例子是用于iPhone等智能手機的DBPedia Mobile，它消費DBPedia的地點信息幫助旅行者探索某個城市。不僅集成DBPedia上現有的RDF數據，還支持用戶即時發布自己的數據，并以RDF格式保存在DBPedia上，以供其他用戶使用。這在很大程度要歸功于DBPedia所提供的強大的數據接口，包括數據消費接口和數據輸入接口。

3 關聯數據的消費技術

從流程來看，關聯數據的消費涉及到數據的訪問和獲取、發現、查詢、交換和傳輸、處理和利用等方面，本文在此對這個過程中所涉及到的基本技術做一個梳理和總結。

3.1 數據的訪問和獲取

對關聯數據的一種簡單直接的訪問和獲取方式是根據關聯數據的四原則，直接訪問資源對象的URI來獲取關于資源對象的信息。關聯數據建立在URI、HTTP等基礎的互聯網技術之上，每一個資源對象（Object）都有全球唯一的HTTP URI，它集標識功能和定位功能于一身，并且是可“解引（Dereferenced）”的，即可通過訪問資源對象的URI來獲取關于這個資源對象的信息，這些信息可以是一個html頁面，也可以是基于某種序列化格式的RDF數據。在《發布關聯數據的最佳實踐》一文中提到：“解引”可通過 HTTP協議的“內容協商（Content Negotiation）”機制來實現，內容協商機制能根據客戶端請求的類型（一般在HTTP Header信息中指定）返回相應格式的數據，若是普通瀏覽器，服務器會自動返回HTML數據，若是語義瀏覽器，則返回RDF數據。該文還推薦了兩種最佳實踐，即帶＃（Hash）的URI的實現方式和303轉向的實現方式，如：http：／／linkeddata.openlinksw.com／about／Berlin＃this就是一個帶“＃”的URI［9］。圖1是用PHP實現303轉向的一個例子，首先要保證服務器能接受的MIME類型包含客戶端所要請求的類型，如application／rdf＋xml，如在瀏覽器中輸入http：／／lod.library.sh.cn／test303／foaf，返回 HTML數據，輸入http：／／lod.library.sh.cn／test303／foaf.rdf，則返回RDF／XML數據。

圖1 用PHP實現303轉向

對關聯數據的另一種訪問和獲取方式是利用數據集或語義搜索引擎提供的消費接口：如Sparql端點、Restful Web Services接口、OpenSearch／SRU、各種客戶端開發庫、專用API等，將在本文第4部分詳細分析。

3.2 數據的發現

通常把同類數據的集合稱作一個數據集（Dataset），目前Web上的關聯數據大多以數據集的形式發布，當Web上的關聯數據集越來越多時，就需要引入一種發現機制，作為數據發布者和數據消費者之間的橋梁，如建立一個注冊機構或公開目錄，提供關于數據集的數據，即數據集的元數據，就是有助于數據被發現的途徑之一，尤其是機器的自動發現。VoID（Vocabulary of Interlinked Datasets）是一個基于RDFs的詞表，定義了描述關聯數據集的元數據方案［10］。VoID包括四個方面的元數據，其中“訪問（Access）”元數據用于描述RDF數據使用何種協議訪問，結構性元數據用于描述數據集的結構和模式，利于數據的查詢和整合，對數據集之間的關系的描述有助于理解多個數據集之間的關系和不同的數據集之間如何整合利用。thedatahub.org就是這樣一個為數據集提供注冊機制的公開目錄，截至目前，thedatahub.org的子集 LOD（Linking Open Data Cloud）已建立了一個包含328個相互關聯的關聯數據集的公開目錄，每個關聯數據集都用VoID描述，如數據打包下載的URL地址，Sparql端點的URL地址，API的URL地址等信息，用于關聯數據的發現和消費。DBPedia也有自己的VoID描述。

3.3 數據的查詢

根據關聯數據的四原則，數據要盡量采用RDF數據模型。RDF數據通常表現為一堆三元組的集合，描述某個資源的一個或多個三元組稱為一個RDF圖（Graph）。消費方要查詢RDF圖中的數據單元并對其進行處理，需要借助專用的RDF查詢語言，如W3C的Sparql，Sparql已在2008年1月成為W3C的推薦標準，是目前使用最為廣泛的RDF查詢語言［11］。Sparql允許從RDF庫（通常包含多個RDF圖）中查詢三元組，與關系數據庫相比，RDF庫是一個龐大無序的三元組集合，RDF數據沒有外鍵和主鍵，只有URI，Sparql查詢通過定義匹配三元組的RDF圖模式（Graph Pattern）來完成，RDF圖是用一個全球可定位的HTTP URI來唯一標識，而不是物理意義上的數據庫名和表名，如查詢URI為＜http：／／lod.library.sh.cn：8080／bib＞這個 RDF圖中dc：creator為“巴金”的所有主語的Sparql語句為：

這種方式簡單而直接，無需了解底層的數據結構，甚至可以指定多個不同 URI（RDF圖）同時查詢：

Sparql查詢結果也是URI，而URI是 Web的標準引用格式，通過URI，可以連接到Web上的任何數據，這就突破了關系數據庫查詢語言一次只能在單個數據庫中查詢的局限，整個Web于Sparql語言而言是一個巨大的整體的數據空間。基于Sparql語言和Sparql協議的Sparql端點技術，為查詢關聯數據集提供了標準的接口，可供人機檢索，為大部分關聯數據集和語義搜索引擎采用，在此基礎上，出現了基于多個Sparql端點的聯邦Sparql檢索引擎，可整合不同的數據源的數據。另外，還有一些非標準的RDF查詢語言，如Freebase定義了一種類似于Sparql的查詢語言 MQL，專門用于查詢Freebase中的數據。Sindice為自己的消費接口定義了專用的查詢語言Sindice Query Language。

3.4 數據的序列化

RDF只是一種抽象的數據模型，而不是一種具體的數據格式，要使RDF數據成為機器可讀的數據，就需要對其進行序列化（Serialization）。序列化的RDF數據可以通過HTTP協議傳輸和交換，這樣應用程序可以對這些數據進行遠程獲取和處理，有利于不同的操作系統、程序語言之間的互操作。目前有諸如 RDF／XML，RDFa／JSON／JSONP，N3，Turtle等不同的序列化格式，其中RDF／XML和RDFa是W3C的推薦標準，其他的序列化格式則為滿足不同的具體需求而設計。RDF／XML是RDF模型最為經典的序列化方式，與XML Schema配合使用，基于XML編碼的RDF甚至能實現不同應用領域之間的互操作，但RDF／XML有著不利于人讀和寫的缺點。RDFa是將RDF三元組嵌入HTML文檔的一種序列化格式，適用于能方便修改HTML文檔模板但難以介入系統體系架構的應用，如Drupal等內容管理系統［12］，這種序列化方式不能很好地支持內容協商機制。Turtle是一種純文本的RDF序列化格式，適用于人讀和寫，N－Triples（N3）是Turtle的一個子集，因其規定每一個三元組中的主體、謂詞、客體都必須用完整的URI來表示，如：＜http：／／lod.library.sh.cn：8080／bib／resource／PersonA000001＞ ＜http：／／www.w3.org／2002／07／owl＃sameAs＞ ＜ http：／／dbpedia.org／resource／Ba＿Jin／＞。所以與 Turtle和 RDF／XML相比，文件會比較大，但這也是它的優點，因為它的每一行都可以單獨解析，同時它也很適合壓縮以減少在傳輸交換過程中的網絡流量，這種特性使得N3成為適合傳輸大型關聯數據包的一種序列化格式。JSON（JavaScript Object Notation）是一種適合于程序處理的RDF序列化格式，大部分程序語言本身就提供處理JSON數據的功能，如JavaScript和PHP，將RDF數據發布成JSON格式可使程序開發員無需安裝額外的開發包就能處理RDF數據。目前一些關聯數據消費接口一般都會提供一種或幾種格式的數據以內容協商的方式返回給客戶端，如DBPedia的Sparql端點就提供RDF／XML，JSON，N3等多種數據格式。而一些面向機器的消費接口則以JSON格式為主。

3.5 數據的處理和利用

在數據消費的過程中，訪問和獲取、發現和查詢、傳輸和交換的最終目的是為了將數據拿來為我所用。一般有這樣幾種利用方式：（1）為本地數據建立外部關聯，如上文提到的西班牙國家圖書館的關聯書目數據；（2）多種數據混搭建立新的應用和服務，如社會書簽工具Faviki，利用DBPedia、Freebase等作為背景知識庫，通過關聯數據的URI技術來消除歧義，提供分主題組織的標簽導航服務；（3）發現數據之間的關聯關系建立知識地圖，如生命科學領域的關聯數據應用Diseasome Map，整合來自不同的生命科學領域的數據資源，生成一個相互關聯的病毒基因網絡；（4）進行語義挖掘和推理發現有用的信息，如Researcher Map是一個基于FOAF的關聯數據應用，通過DBPedia和DBLP關聯數據集中的RDF Links來發現德國教授的個人信息。在數據處理和利用的過程中，要對數據查詢結果提取和重組、分析和計算，需要基于一些已有的標準規范，也需要一些開發包來支持。在標準規范層面，一些早期的語義網技術的成果如 RDF／XML、Sparql、OWL，其標準的制訂和技術的應用已經成熟；在應用開發層面，一些流行的編程語言都有處理RDF數據的開發包，如 Java的 Jena、Sesame、Kowari ，PHP 的RAP，以支持Sparql協議向Sparql端點發起Sparql查詢、處理查詢結果、讀寫序列化的RDF數據文件、操作原生RDF數據庫等［13］。還有一些集成的客戶端開發庫如PHP的ARC2，被Drupal等開源平臺集成，作為后臺關系數據庫和前臺Sparql端點之間的中間件，提供實時的Sparql查詢到SQL查詢、SQL查詢結果到Sparql查詢結果的雙向轉換。在數據處理的過程中，不可避免會涉及到不同本體或詞表間的映射，R2R詞表映射框架可以幫助關聯數據應用在Web上發現一些未知的術語、術語之間的映射，并利用這些映射將Web上的數據轉換到應用的宿主詞匯表，有助于發現異構數據之間的關系。數據混搭語言MashQL提供了另一種整合數據的思路，它將整個Web看成一個大的數據庫，每個數據源看成是數據庫中的一張表，消費者可以不必關心各個數據源所用的詞表和技術細節［14］。

4 關聯數據的消費接口分析

一個優秀的關聯數據集，在發布時就應考慮如何被消費，盡可能地提供便于數據消費者調用的消費接口，大型的關聯數據集如DBPedia、Freebase就提供多種方式、多種功能、適應不同需求的數據消費接口。一些語義搜索引擎后臺有著不斷更新壯大的海量RDF數據，在Web上有供人檢索的入口，也有供機器獲取數據的開放數據接口。一些數據集成管理平臺本身的功能模塊可提供不同接口以支持關聯數據集的消費。筆者調研的DBPedia、Freebase、Nature.com、Data.gov、VIAF 等典型的關聯數據集，＜sameAs.org＞、SWSE、Sindice、Swoogle、Falcons等流行的語義搜索引擎，CKAN、Openlink Software、Tailis Plateform等大型數據集成管理平臺所提供的消費方式和消費接口主要有這幾種：批量下載、Sparql端點、RESTful Web Service接口、OpenSearch／SRU、專用 Web Service接口、專用API、專用客戶端開發包、插件（Plugin）／小工具（Widget）。目前關聯數據所提供的消費接口有如上所列的多種或全部，每個調研對象的詳細情況見表1、表2、表3。

表1 關聯數據集（Linked Data Sets）的消費接口

表2 語義搜索引擎（Semantic Search Engine）的消費接口

表3 工具／平臺所提供的消費接口

批量下載。早期的關聯數據集一般會將所有的RDF數據打包，在 Web上提供批量下載地址。作為數據消費方，需要將這些打包的RDF數據下載到本地，在本地存儲，供本地系統重用這些數據。目前，仍有許多關聯數據集沿用這一做法，如DBPedia、Freebase、CKAN、VIAF、Data.gov.uk等。DBPedia以每2－3個月更新一次的頻率發布了多個版本，2012年8月6日發布了3.8版，相較于3.7版，在數據量、數據的內容范圍、組織方式上都有一些增加和改進。CKAN則提供幾種方式讓消費方自己制作CKAN數據的打包文件。VIAF提供RDF／XML，MARC21／XML等多種格式的打包文件批量下載。有的關聯數據發布平臺提供RDF數據包的打包工具，如D2RServer的Dump－rdf，可將整個關系數據庫轉換為RDF數據包。這種批量下載的消費方式要求數據提供方和數據消費方都要考慮到數據集的更新頻率，發布方要考慮到數據發布的版本管理，消費方要密切關注數據發布的動態，考慮是否需要及時更新本地數據。

Sparql端點是目前最為流行的關聯數據消費接口之一，幾乎大部分的關聯數據集如DBPedia、na－ture.com、BBC都提供這種消費接口，大部分的關聯數據發布工具／平臺如D2RServer、Drupal、Pubby、LDIF、Virtuoso等都提供Sparql端點的技術支持，可以說Sparql端點是關聯數據發布時的標準配置。它既可提供Web界面用于人的瀏覽，也是機器訪問和獲取數據的接口，人通過普通瀏覽器訪問關聯數據集的 Sparql端點網址（如：http：／／DBpedia.org／sparql），輸入并編輯Sparql查詢語言，選擇所需的數據編碼格式，點擊一個按鈕即可獲得返回結果的RDF數據。對于機器來說，要通過Sparql端點訪問或獲取某一關聯數據集的數據，通常需要借助處理Sparql查詢的客戶端開發庫如Jena的ARQ。相比而言，基于Sparql端點的消費方式對于消費方來說有較高的技術門檻，要求消費方進行一定的編程工作，對于發布方來說則無此顧慮，因為大多數關聯數據發布工具、平臺都以提供Sparql端點為標準配置。

Restful Web Services是一種輕量級的Web Services，利用URI、HTTP等簡單通用的Web標準及技術，對數據進行讀取、寫入、修改、刪除等操作，是目前最為流行的數據接口，大部分的數據集、語義搜索引擎、關聯數據管理平臺都提供這種數據消費方式，見表1、表2、表3。一種簡單的基于Restful Web Services的數據消費方式是數據消費方直接訪問某一資源對象的URI，通過內容協商機制，獲取該資源對象某種指定編碼格式的RDF描述。例如，當數據消費方需要獲取VIAF的某一資源對象數據時，可以直接訪問該資源對象的 URI：http：／／www.viaf.org／viaf／75785466／，若需返回 XML 格式 的 數 據，則 訪 問 http：／／www.viaf.org／viaf／75785466.xml，若需返回純rdf數據，則訪問http：／／www.viaf.org／viaf／75785466.rdf。表4 是VIAF的RESTful Web Service請求和響應的對照表。

更為復雜的Restful Web Services利用URL傳遞事先定義的參數或專用的結構化檢索語言向服務器發送數據查詢或處理請求，服務器返回既定或由客戶端指定的內容和格式。例如VIAF的AutoSuggest接口，其語法為：http：／／viaf.org／viaf／AutoSuggest？query＝［searchTerms］＆callback［optionalCallback－Name］，返回數據的格式為JSON。DBPedia的Lookup Service，其 語 法 為：http：／／lookup.dbpedia.org／api／search.asmx／＜API＞？＜parameters＞。其中＜API＞是指從DBPedia申請的API Key，用于權限控制。還有Freebase的各種Search API如根據關鍵詞查找實體的Search Service、獲取一個實體的概要信息的Topic API、獲取實體的簡單文本型描述信息的Text Service，獲取圖像實體的拇指圖的Image Service。其中Search Service的語法為：https：／／www.googleapis.com／freebase／v1／search？q＝bob＆key＝＜YOUR＿API＿KEY＞。Sindice的Search API（v3）使用自定義的查詢語言詳細定義了十多種參數，包括關鍵詞、詞表及屬性、返回結果的格式等，如：http：／／api.sindice.com／v3／search？q＝Rome＆fq＝class：city＆format＝json。Sindice基于其自定義的Sindice Query Language的API支持關鍵字匹配、三元組查詢和各種過濾策略。Tailis平臺的Augment Service API能對來自不同數據集的返回結果進行合并處理。Tailis平臺的Full Text Searching API不僅可以利用自定義的全文檢索語言通過在URL傳遞事先定義好的參數對數據集中的數據進行全文檢索，還可以傳遞Sparql查詢語言來查詢數據集中的數據，甚至可以對數據集中的數據進行修改和刪除。這種方式對于消費方來說使用方便，但發布方需要考慮到數據傳輸中的安全問題，如是否需要數據加密和權限控制。

表4 OCLC viaf的請求／響應對照表［15］

OpenSearch／SRU。OpenSearch的是Amazon.com子公司A9公司所提出的一種分享查詢結果的簡單的格式標準，2005年3月首次在O'Reilly新興技術會議上提出OpenSearch1.0版本，目前使用版本為1.1版。OpenSearch與國會圖書館的結構化查詢規范SRU結合，同樣是利用URL傳遞參數返回指定格式的結果數據，但這里的參數不是自定義而是標準的結構化查詢語言CQL，如CKAN和VIAF提供OpenSearch接口，而nature.com則提供OpenSearch和SRU整合的消費接口［16］。VIAF的OpenSearch 查 詢 舉 例：http：／／viaf.org／viaf／search？query＝cql.any＋all＋%22［searchTerms］%22＋＆maximumRecords＝100＆startRecord＝［startIndex］＆sortKeys＝holdingscount＆httpAccept＝application／rss%2bxml，VIAF還提供一個可視化的界面，只需要選擇一些參數的值，系統會自動生成包含CQL查詢的OpenSearch URL。這種方式建立在OpenSearch、SRU、CQL等標準和技術之上，對于消費方來說，無需進行復雜的編程運算，又能靈活方便地直接獲取關聯數據集中的數據單元，但需要掌握CQL語言。對于發布方來說，可以植入自定義的認證和授權規則，有利于數據的安全和版權控制。

專用Web Service接口。如DBPedia所提供的“公開分面 Web Services 接口”，http：／／DBpedia.org／fct／service建立在 Openlink Software公司的Virtuoso分面 Web Services接口基礎上，該 Web Services接口定義了一系列的HTML標簽，在這些標簽中可以寫入Sparql語言。當在本地Web應用的HTML網頁上嵌入這些標簽時，服務器會返回所請求結果的XML格式數據，供本地網頁用自定義的XSLT為用戶提供數據展示界面［17］。

專用API。這種方式是發布方通過API來精心包裝自己的數據，甚至定義專用的查詢語言，開發出專用于特定數據獲取和處理的方法以供消費方在編程時調用。一般會詳細定義輸入參數和返回結果，還有對返回結果進行處理的方法，同時有可靠的授權控制機制如API Key、Web ID等。如CKAN的各種API，允許消費方傳入指定的屬性值，返回特定的結果。還有Freebase基于其MQL的各種API。這種方式需要發布方進行大量的開發工作，將數據訪問、查詢和處理過程封裝起來，對用戶透明，只根據用戶的輸入參數按需提供結果數據，而消費方需要深入了解API的使用方法，對發布方和消費方都有較高的技術門檻。

專用客戶端開發包。一些大型的關聯數據集為了滿足不同消費者的個性化需求，為數據消費提供無限的可能，開發出專用的客戶端開發包，供程序員編程使用。如Freebase提供JavaScript、Flash、Python、Perl、PHP、Ruby、Clojure、Java、NET、Objective－C 10種語言的客戶端開發包，同時提供基于JavaScript的Arce集成開發平臺，有著大量利用Freebase的數據構建本地應用的開發工具。CKAN也提供專用的客戶端開發庫，目前有Java、PHP、JavaScript、Python、Rubby，PERL6種語言的客戶端開發庫，利用這些客戶端開發包，消費方可以靈活地獲取、使用、甚至修改CKAN中的數據，進行復雜的計算。語義搜索引擎sameAs.org提供Java開發包sameas4j，Sindice提供Java和Pyhton等簡單的工具包。

插件、小工具。在Web2.0時代，插件和小工具以其靈活、小巧，可自由嵌入等特點風行一時，這些優點在語義網世界繼續發揚光大，如thedatahub.org的基于Chrome瀏覽器的插件JSONView for Chrome，可以在Chrome瀏覽器上瀏覽它的數據，還有 Google Refine CKAN Extension，DBPedia 的DBpedia Lookup服務插件，可以裝在本地服務器上，其功能是通過關鍵詞或簡寫查找某一實體的URI。Freebase用于移動設備上的App如Freebase Explorer Android App。Sindice的基于Drupal的MOAT module，可以在Drupal站點中消費Sindice提供的數據。

5 技術實現案例

案例1：直接利用外部數據的URI為本地數據添加外鏈。

要向本地數據集——名人規范檔中的實體添加到DBPedia的外鏈，用owl：sameAs作關聯。首先了解到DBPedia中對某一人（Person）的實體的URI命名規則是 “http：／／dbpedia.org／resource／”＋ 人名，若是中國人，人名是姓名的拼音，如巴金的URI是http：／／dbpedia.org／resource／Ba＿Jin／，這樣，就可以把本地數據集中的巴金用owl：sameAs鏈接到DBPedia的巴金，用三元組來表示，即：＜http：／／lod.library.sh.cn：8080／bib／resource／PersonA000001＞owl：sameAs＜http：／／dbpedia.org／resource／Ba＿Jin／＞。其他的人則可以由此規則類推，只要計算出本地數據集中所有人物實體的姓名的拼音，如矛盾的拼音是Mao＿Dun，其 URI就 是 http：／／dbpedia.org／resource／Mao＿Dun／，采用這種數據消費方式，需要數據發布方有明晰的URI命名規則或者提供根據關鍵詞查詢URI的服務，數據消費方也要對目標關聯數據集的URI命名規則或URI獲取方式有所了解，才能準確地獲知某一資源對象的URI。

案例2：利用Restful Web Services獲取數據。

要獲取本地數據集中的實體在VIAF中的URI，首先了解到VIAF的URI命名規則是“http：／／viaf.org／viaf／”＋VIAF ID，只要獲取了某一實體的VIAF ID，就可以知道這一實體在VIAF中的URI。這時可以用VIAF的AutoSuggest接口，獲取本地數據集中某一實體在VIAF中的同一實體的VIAF ID，以巴金為例，在URL中傳遞參數bajin，http：／／viaf.org／viaf／AutoSuggest？query＝bajin，返回的結果為JSON格式的數據，如下：

上述結果中包括viafid這個屬性的值19673501，此即巴金的VIAF ID，由此可知巴金在VIAF 中 的 URI 為 http：／／viaf.org／viaf／19673501。可以用程序讀取所返回的JSON數據，取得VIAF ID的值。

案例3 基于Java利用ARQ客戶端編程向多個Sparql端點獲取數據。

已知DBPedia的Sparql端點的URL地址為：http：／／dbpedia.org／sparql。利用 ARQ 開發包，它支持指定關聯數據集的Sparql端點的地址，就可以遠程訪問和獲取數據。如下為部分程序片段：

6 總結與展望

基于關聯數據技術框架的數據消費可以做到真正意義上的分布式和跨數據源的查詢，實現基于語義的全Web集成。各種大型公開的關聯數據集和語義搜索引擎提供了海量的富含語義的結構化數據，成為Web上的公共數據中心，多樣化的數據消費接口為數據消費者利用數據帶來了無限的可能。但是，目前關聯數據的消費接口，除了Sparql端點外，其他的方式包括Restful Web Services接口，尤其是各種專用的API，因其使用方法各不相同，有的還異常復雜，尚未形成統一的標準，對消費方來說頗為不便，成為阻止關聯數據得到有效利用的障礙之一。在系統和平臺的開發上，進入此領域的大型商業公司并不多，為大英圖書館提供關聯數據體系架構的Tailis公司在2012年宣布停止提供關聯數據相關服務，反而在大學和研究機構，涌現出越來越多的開源項目，但對于普通消費者來說，開源軟件的使用仍然存在著較高的技術門檻。隨著關聯數據的發布越來越呈現出分布式、虛擬化、關聯化的特征，關聯數據的消費也將更多地依賴于接口的標準化。另一方面，數據來源跟蹤和數據質量檢測的機制的建立，是來自技術之外的挑戰。

1 劉煒.關聯數據：概念、技術及應用展望.大學圖書館學報，2011（2）：5－12

2 黃永文.關聯數據驅動的Web應用研究.圖書館雜志，2010（7）：55－59

3 白海燕.關聯數據及DBPedia實例分析.現代圖書情報技術，2010（3）：33－39

4 林海青.關聯書目數據：發布、查詢、消費及混搭.“從文獻編目到知識編碼：關聯數據技術與應用”專題研討班.2012，7.［2012－08－21］.http：／／conf.library.sh.cn／sites／default／files／LBD 的 查詢消費及混搭＿林海青.pdf

5 夏翠娟.關聯數據的技術實現及案例.“從文獻編目到知識編碼：關聯數據技術與應用”專題研討班.2012，7.［2012－08－21］.http：／／conf.library.sh.cn／sites／default／files／LD的技術實現及案例＿夏翠娟.pdf

6 Li Ding，etc.Swoogle：A Search and Metadata Engine for the Semantic Web，the Thirteenth ACM Conference on Information and Knowledge Management，November 2004.

7 Li Ding，etc.Finding and Ranking Knowledge on the Semantic Web，in the Proceedings of the 4th International Semantic Web Conference，November 2005

8 Tom Heath，Christian Bizer.Linked Data：Evolving the Web into a Global Data Space.Synthesis Lectures on the Semantic Web：Theory and Technology，1：1，1－136

9 Diego Berrueta，Jon Phipps.Best Practice Recipes for Publishing RDF Vocabularies.［2012－08－31］.http：／／www.w3.org／TR／swbp－vocab－pub／

10 Keith Alexander，etc.Describing Linked Datasets with the VoID Vocabulary.［2012－08－31］.http：／／www.w3.org／TR／void／.

11 Olaf Hartig，Christian Bizer，Johann－Christoph Freytag.Executing Sparql Queries over the Web of Linked Data.Lecture Notes in Computer Science，2009，Volume 5823／2009：293－309.

12 夏翠娟等.關聯數據的發布技術及實現——以Drupal為例.中國圖書館學報，2012（1）：49－57

13 Christian Bizer，Daniel Westphal.Developers Guide to Semantic Web Toolkits for different Programming Languages.［2012－08－ 21 ］.http：／／www. wiwiss.fu－berlin. de／suhl／bizer／toolkits／06062006／

14 Mustafa Jarrar，Marios D.Dikaiakos.A Data Mashup Language for the Data Web.［2012－08－31］.http：／／events.linkeddata.org／ldow2009／papers／ldow2009＿paper14.pdf

15 OCLC.Virtual International Authority File：Using the API.［2012－08－26］.http：／／www.oclc.org／developer／documentation／virtual－international－authority－file－viaf／using－api

16 Tony Hammond.nature.com OpenSearch：A Case Study in OpenSearch and SRU Integration.［2012－08－13］.http：／／www.dlib.org／dlib／july10／hammond／07hammond.html

17 Openlink Software.Virtuoso Facets Web Service.［2012－08－24］.http：／／virtuoso.openlinksw.com／dataspace／dav／wiki／Main／VirtuosoFacetsWebService