一個鏈結資料(Linked Data)實作的調查

美國國際圖書館電腦中心(OCLC, Online Computer Library Center)在2014-15年間對全球的圖書館和博物館進行問卷調查,想了解全球的圖書館和博物館界在鏈結資料(Linked Data)的執行狀況,這個調查收集了20個國家90個機構的回應,問卷的原始資料在此,根據這個問卷資料,Karen Smith-Yoshimura 在2016年於D-Lib上發表了一篇文章,以下的內容是來自於這篇文章。

以機構的類別而言,調查對象是以圖書館為主,博物館比例較少。在這90個機構中,有些已經進行鏈結資料的工作超過二年,但也有為數不少的機構其實還沒有開始鏈結資料的工作。

機構進行鏈結資料工作有多久?

如何使用鏈結資料?以鏈結資料的使用而言,多數的單位鏈結資料的使用者,相對地,發佈者比例則較低。

調查如何使用鏈結資料?

那發佈鏈結資料的單位,因為調查對象是以圖書館為主,他們所發佈出來的資料類型,是以書目資料、描述的詮釋資料、權威檔、知識本體/語彙為主。若以發佈鏈結資料的動 機而言,大多數的單位認為資料轉為鏈結資料後,可以擴大資料的使用範圍。

發佈鏈結資料的動機

雖然許多機構的鏈結資料的計畫都是在剛起步的階段,能夠說出鏈結資料工作的成功之機構是相對低的,整理了46個機構的回饋,導出幾個成功的鏈結資料工作之指標:

  • 資料重複使用 (Data re-use).
  • 增加被搜尋 (Increased discoverability)
  • 新知識的建立 (New knowledge creation)
  • 思想的領先者 (Thought leadership)
  • 對於語意網的準備 (Preparation for the semantic Web)
  • 操作的順利進行 (Operational success)
  • 促進機構的發展 (Organizational development)
  • 促進機構的轉型 (Organizational transformation)

其文章也列出其他原因,包含:

  • 在未來的計劃需要發佈鏈結資料來利用及重複使用。
  • 最大化資料的互操作性和重複使用性。
  • 測試 BIBFRAME 和 schema.org。
  • 計畫需求。
  • 提供穩定、整合、正規化資料在跨機構的研究活動。

被提到發佈鏈結資料的障礙依序為:

  1. 學習曲線對員工太高
  2. 和舊有的資料不一致
  3. 選擇合適的知識本體來呈現資料
  4. 建立連結
  5. 在如何建立系統有輕量文件或建議
  6. 工具的缺乏
  7. 不成熟的軟體
  8. 弄清楚資料是誰的

最後,文章整理了受訪者給要進行鏈結資料計畫的單位一些建議:

  • 聚焦於你所要完成的目標,而不是技術的東西
    • 模型化你所要解決之案例的資料
    • 往長期的資料一致和統合 (data reconciliation and consolidation) 之方向去努力
  • 增加獨特的價值: 建立在你有但別人沒有
    • 挑出你可以解決的問題
    • 帶入你所處的機構/社群來思考
  • 對於鏈結資料結構、可取得的知識本體和你的資料能有好的理解
    • 消化你所發佈的資料
    • 一開始就考慮法律授權問題
    • 盡量廣泛地參考相關資料且諮詢專家
  • 現在開始! 就去做吧!

資料轉成RDF就是4星級資料了嗎?

因產銷履歷農產品鏈結資料之計畫所需,在data.gov.tw上尋找食品業者登錄資料集,意外的發現這筆資料居然提供RDF格式,不但如此,衛福部食藥署還有一個LOD的網頁,集合了他們製作的RDF資料集。引起了我的好奇,去看看這些RDF的資料,若他們的資料與系統完備,我們的產銷履歷農產品RDF資料即可以和衛福部食藥署的RDF資料連結,但看完資料後覺得有些建議,提出來和大家分享。

<rdf:Description rdf:about="http://data.fda.gov.tw/lod/tfda/FoodCompanyRegistration_VIEW/DATA_SN/6833319">
   <rdf:type rdf:resource="http://data.fda.gov.tw/lod/schemas/tfda/FoodCompanyRegistration_VIEW"/>
   <tfda:公司或商業登記名稱>早安!美芝城仁愛店</tfda:公司或商業登記名稱>
   <tfda:食品業者登錄字號>E-200028714-00002-7</tfda:食品業者登錄字號>
   <tfda:登錄項目>販售場所</tfda:登錄項目>
   <tfda:公司統一編號/>
   <tfda:業者地址>高雄市新興區仁愛一街177號</tfda:業者地址>
</rdf:Description>

上述是食品業者登錄資料集中的一筆資料,沒有了URL,其它的格式的資料沒有什麼不一樣。URL所指涉的是一件事物,讓別人可以去連結這份資料,而在食品業者登錄資料集中,主體是「食品公司」,所以<http://data.fda.gov.tw/lod/tfda/FoodCompanyRegistration_VIEW/DATA_SN/6833319> 指的是一個「食品公司」,即是「早安!美芝城仁愛店」,可被連結的。「早安!美芝城仁愛店」是一個實例(instance),而「食品公司」則是類別(class),因此rdf:type中應該指的是「食品公司」,就是<http://data.fda.gov.tw/lod/schemas/tfda/FoodCompanyRegistration_VIEW>。

1. URL 設計不良

邏輯上,這個RDF 的表達沒有錯,但就URL的設計而言,實在很糟禚。為什麼不簡單清楚一些? 例如,類別的名稱簡單清楚,用FoodCompany取代FoodCompanyRegistration_VIEW,因此,<http://data.fda.gov.tw/ontology/FoodCompany>來指食品公司的類別(class),而<http://data.fda.gov.tw/ontology/FoodCompany/6833319>來指「早安!美芝城仁愛店」這家店。

其實URL的設計是有一些原則,其詳情可以參考W3C的文件 Cool URIs for the Semantic Web

2. RDF與知識本體應一致

再者,這份RDF中的標籤使用中文,但知識本體的宣告卻是英文,這樣的做法機器是沒辦法知道RDF內用中文宣告的屬性,在知識本體中是對到那一個英文。或是說URL根本就不一樣,怎麼有可能對在一起!

3.提供SPARQL查詢

RDF資料通常會利用三元組儲存庫(triple stores)來管理、儲存和查詢資料,這些三元組儲存庫通常也可以透過網路提供SPARQL的查詢服務,因此常稱為SPARQL endpoints,這些工具的技術都己經成熟,而且也有自由軟體可以利用,同時因開放碼源,也可以客製化成自己需求的服務,如果使用者還是把資料下載再使用,那用URL去指稱事物的功能,在網路上就無法發揮更好的效用。

4.缺乏利用既有語彙

為了資料容易整合,在建立資料知識本體時,多考慮使用標準或既有的語彙為主,以增加資料的可再使用性。食藥署的這批RDF資料,無論在類別或屬性都有標準或既有的語彙,是可以考慮多使用這些語彙。