G20農業鏈結開放資料會議 Part 1

會議背景

LOD in Agriculture Workshop 做為G20 農業首席科學家會議(MACS)之一,聚集農業科技上的科學共同討論農業資料之標準化、結構化、鏈結化、及應用上的問題,這個會議是由GODAN ( Global Open Data for Agriculture & Nutrition)、 德國農業部(BMEL)、和德國農業科技與建立協會(KTBL)等三個單位來共同舉辦。

值得一提的是,GODAN是一個5年的跨國合作計畫,規模為850萬美元,由美國政府、英國政府、荷蘭政府、開放資料研究所(Open Data Institute, ODI)、聯合國國際農糧組織(FAO)、歐盟支援的農業研究與創新全球論壇(The Global Forum on Agricultural Research and Innovation, GFAR)、農業和生物科學國際中心(Centre for Agriculture and Biosciences International, CABI)、國際農業研究諮議組織(Consultative Group on International Agricultural Research, CGIAR)、農業與農村合作技術中心(Technical Centre for Agricultural and Rural Cooperation, CTA)、 和食物與農業研究基金會(Foundation for Food and Agriculture Research, FFAR)等10個單位共同出資,目前全球共有579個公私立單位參與成為該計畫夥伴。

會議開場

會議開場是由德國農業科技與建立協會(KTBL)的 Daniel Martini 主持。首先,由德國農業部(BMEL)官員致詞,說明會議舉辦的背景,是由於德國今年於漢堡(Hamburg)舉辦G20會議,並因此在波茲坦(Potsdam)舉辦G20中首席農業科學家會議(MACS),而去年的G20會議在中國時,就強調資通訊科技在農業上的應用與發展,延續這個議題,有鑑於歐盟近5年來在鏈結資料上的發展,德國今年則嘗試以鏈結資料在農業上的討論為主來承續中國在去年開啟的議題。而他也說明,雖然這是G20的會議之一,但這個會議其實不侷限於G20的成員參與,而是著重於農業和食物科學議題討論,而開放資料的策略提供更多在農業議題脈絡中創新的機會,有助於解決當前全球共同面對的農業和食物問題。

接著是GODAN計畫祕書的Johannes Keizer博士致詞,他是前FAO官員,退休後持續在全球的農業和糧食議題上努力,尋求更多解決的方法。他認為開放資料是解決全球農業和糧食問題的重要策略,許多的經濟效益是可以由開放資料而來,

而開放資料的重要的內涵在於資料再利用,產生資料流動,資料不斷地流動,才有可能有經濟效益和價值,開放資料也透過資料分享、知識分享,讓整個系統更有效率、更加有力量,更加的堅固。資料要流動,就必須讓資料能夠被找的到,資料要再被利用,就必須讓資料的語彙共通。

如何透過開放資料建立更好的農業和糧食資料的利用,進而解決問題,是GODAN計畫在尋找的解決方案,全球各地許多科研單位和科學家加入。他也強調,在剛結束不久的科研資料聯盟(Research Data Alliance, RDA)第10次會議於加拿大蒙特婁(Montréal)舉辦,其中有許多議題都和鏈結資料有關,而鏈結資料的技術與方法在農業和糧食問題的研究發展方興未艾,本次的會議就是想更深入去探討農業上的鏈結資料。

最後,由Daniel Martini給了一些開場的結語,他強調這個會議嘗試找出鏈結資料如何在農業上有用,農業資訊如何能透過當代資通訊技術製造更多的經濟效益,而這些議題不單單是德國的問題,而是全球的議題。

Keynote

會議主辦方邀請Elsevier的Paul Groth博士,以 「The Roots: Linked Data and the Foundations of successful agriculture data」為題進行專題演講。Groth博士先自我揭露說,他的科學背景是電腦科學,著重於開放資料和鏈結資料,而非農業領域,但家鄉是荷蘭,是非常重視農業科技的國家,也算是和農業扯上邊。

他先以三個問題來揭開專題演講,這些問題也是整演講的脈絡。

  1. 鏈結開放資料如何能讓農業不同以往? (How can Linked Open Data make a difference in agriculture? 
)
  1. 什麼樣的技術門檻阻礙了這個發展? (What technical obstacles stand in the way?)
  1. 什麼樣的政策需要配合? (What policies are needed to achieve the potential?)

他首先強調資料在農業的重要性,以精準農業為例說明資料是農業的中心。如圖1所示。他進一步引用Wolfert等人(2017)的文章,藉由該文的農業資料供應鏈之回顧分析中,說明了農業資料的問題,包含了格式、異質的資料來源、資料清理和準備的自動化、語意的異質性等,而這些正是鏈結資料技術可以應用的地方。

圖1: 資料是精準農業的中心

而研究科學資料在很早以前就開始討論資料開始的議題,在國際科學理事會(ICSU)帶領下,國際科學與技術資料委員會(CODATA)及研究資料聯盟(RDA)的會議中不斷地探討科學資料開放的議題,也使得投入科學資料開放的研究者愈來愈多,Groth博士以他為共同作者的Scientific Data期刊文章「The FAIR Guiding Principles for scientific data management and stewardship」為例,引導了科學資料中倡議開放資料的FAIR 原則,即是Findable, Accessible, Interoperable, 和Reusable,其節細內容如圖2,而達到FAIR原則所導向是成功的資料,而達成成功資料的最佳途徑就是鏈結資料。

圖2: FAIR原則
(來源: Wilkinson et al., M.D. 2016, The FAIR Guiding Principles for scientific data management and stewardship, Scientific Data 3, 160018)

資料再使用(reuse)成為科學資料開放的重要議題之一,要被使用就要找得到資料,要讓科學家能把自己的研究資料開放,資料引用(Data Citation)的制度是一個不可缺或因素,近年來也逐漸形成風氣,許多大型的期刊論文出版商目前都有資料論文(Data paper)的制度,且有些已經進入SCI索引。但這些似乎還不夠,期刊論文的使用者是科學家,對於一些特定群體的行為和需求則不一定滿足,例如,年輕科學家、政策制定者、學生等,觀測資料的背景使用比前景使用有較好的文件說明,也常有人需要資料而從別人的期刊論文中之表格再把資料再製,也有人會在搜尋引擎上尋找,或是直接索取資料。事實上,Google 對於資料集做索引,資料集發佈於網頁時,利用schema.org的語彙於HTML中會有助於Google 對這樣的網頁做索引。

對整合和互操作性而言,Groth博士先以ISOBUS這樣硬體規格,來說明標準所建立的整合和互操作性的重要性,接著解釋農業資料中己經有一些不錯的標準語彙,如AGROVOC和Crop ontology,而AGROVOC是促進農業鏈結資料的重要基礎,GODAN計畫更是重要的推手。資料要跨領域的整合,需要語意和語言的對映,Groth博士以植物知識庫的整合為例,來說明植物資料庫的整合過程,在語言方面,他也以Wikidata為例,說明語彙多語言的整合。

FAIR原則並不只是在於人類趨動的活動,而也著重於機器趨動的活動,因此資料的開放後,要考量的使用者並非只有「人」,還有一個重要的使用者是「機器」,FAIR原則所要克服的是人和機器在網路中尋找和處理處料時個別都會面臨到的問題,要弭平這樣子的障礙,機器學習是一個解決途徑。Groth博士引用吳恩達(Andrew Ng) 博士在2016年史丹福灣區深度學習課程中的一句話。

If there’s a task that a normal person can do with less than one second of thinking, there’s a very good chance we can automate it with deep learning.

也就是說我們現今有太多片段的知識可以透過機器學習建立出知識庫,使得人和機器都可以在語意共通的環境使用資料。接著舉NVIDIA利用深度學習於影像辨識,並將圖片中內容的萃取,例如圖3中,經過機器學習可以萃取出人物、酒瓶、和桌子,而影像辨識也在導入深度學習後,準確度大幅度的改善,圖4說明了ImageNet Large Scale Visual Recognition Challenge 在2012年後利用機器學習後,錯誤大量的減少。

圖3: 以分類來源圖片中每一個像素而產生語意圖的案例 (圖片來源: https://devblogs.nvidia.com/parallelforall/author/czhang/)
圖4: 在 ImageNet Large Scale Visual Recognition Challenge中前5大錯誤的比率在2012年使用用深度神經網路後,錯誤大量減少 (圖片來源: https://devblogs.nvidia.com/parallelforall/author/czhang/)

深度學習的叢集運算可以讓更多的知識由資料中被萃取出來,Groth博士再以ImageNet為案例說明以資料為導向的深度學習將會改變模式的建立,他引用了李菲菲(Fi-fi Li)博士受訪的一段話,

The paradigm shift of the ImageNet thinking is that while a lot of people are paying attention to models, let’s pay attention to data. … Data will redefine how we think about models.

ImageNet企圖建立的知識庫有如WordNet對於知識架構的分類(如圖5),這將有助於機器在處理圖片中的知識。他再舉一個例子是如何從社群媒體的文字描述去了Emoji的意義,如圖6中所示,這些Emoji所群集的分類是由文字描述的自然語言處理,輔以SVM演算法的改良,所得到的結果。

圖5: ImageNet 的概念階層是來自於WordNet 圖片來源: https://qz.com/1034972/the-data-that-changed-the-direction-of-ai-research-and-possibly-the-world/
圖6: Emoji向量在二個維度群集
(下方是國旗、左上方是有關於家庭的符號、在高一點的左上方是星座的符號、最左邊是動物的,中間則是笑臉)
(圖片來源: Eisner, B. et al. (2016). Emoji2vec: learning emoji representations from their description. arXiv:1609.08359v1)

Groth博士接著論述鏈結資料和機器學習的關係,他認為機器可以熟練於學習由文字、語言、圖片和影片中回答問題,是仰賴於我們訓練機器可有效率地由網頁去讀取資訊的能力。先回過頭來看看機器當今如何讀取網頁的,最普遍的方式是搜尋引擎都會做的事,就是透過爬取和索引網頁資源,進一步地可能還有語意化的標籤(例如,使用schema.org),再者,更深層一點的,就語意網的脈絡,可能是尋找且遵循對於知識本體和資料分享和再使用的開放鏈結資料爬取,而在Open API的脈絡而言,機器讀取資料是利用程式可取用的API透過HTTP/S和其它協定來讀取資料,這些機器的讀取方式都需要讓我們去想如何支援標記語言(ML)導向的資料,如XML、JSON、RDF/OWL等。

Groth博士進一步地以FAIR Data的概念來說明資料供應的標準和語彙如何強化資料的品質,在多資料來源和多使用者的平台上更加顯得重要,他就以全球變遷資料庫「The Global Change Information System」來說明如何利用W3C PROV (Provenance Vocabulary) 來幫助平台的資料品質。

圖7: 美國全球變遷資料庫(http://www.globalchange.gov/)

最後,他再回到一開始提到的三個問題,總結而言,他認為要解決這三個問題就是建立成功的FAIR農業資料,而鏈結資料的技術即是建立出FAIR農業資料的關鍵。

英國政府公部門的URI設計

英國政府將政府URI視為資訊基礎建設之一,是「跨政府部門總體架構」(cross-Government Enterprise Architecture, xGEA)一系列的政策和綱領中的一部份,因此英國首席技術辦公室(Chief Technology Officer, CTO)提出「設計英國公部門URI集合(Designing URI Sets for the UK Public Sector)」之報告。

而URI的設計與資料中的概念及其定義有關,有清楚的定義有助資料的分享,以及政府部門發佈和查詢鏈結開放資料。英國政府明確定義URI之目的也在於方便擁有參考性資料(reference data) 的部門,可以讓他們的資料可被再使用(re-use),並且給予那些有可被鏈結資料的部門,可以根據這些規則來使用 URI,因此,URI的定義對於一些與政府部門資料有關係的人更為重要,如在擁有參考資料政府部門、希望透過整併的URI來改善資料再使用(data reuse)的資料擁有者、以及政府部門解決方案的提供者。

報告中指出在2009年時,英國就有一些公部門著手進行URI設計,包含英國廣播公司 (BBC)、英國測繪局(Ordnance Survey)和英國公部門辦公室。經過建立和整合好的實務經驗,對於URI的設計,他們有三個主要重點:

  1. 使用data.gov.uk為URI集合的根網域,以利再使用(reuse)。
  2. URI集合是以部門或機構(如教育、交通、健康等)來分。
  3. 有一致的註釋資料用來描述URI集合的品質特性。

而該份報告所提出的就是一個英國公部門URI設計、架構和原則的技術規範,因此報告中對於URI的進行分類且給予定義,如表1。

表1: URI 類別

資源型態 URI的型態去命名資源 定義/範圍
真實世界的’事物’

Real-world ‘Things’

辨識碼 URI

Identifier URI

這些都是可以在宣告中被指涉的自然或抽象之事物。

自然的真實世界事物,舉例來說,可以是一間學校、一個人、或一條路; 而抽象的事物,舉例來說,可以是一個政府部門、一個族群、或一個事件。

文件或作品也是可以以包含的內容來區別的真實世界事物。

真實世界事物可以大寫的’Things’來表示

一個真實世界事物(Thing)不可能出現在網路中,而只有資訊形容它,因此很重要的是,當有一些宣告是用來指涉它時,事物本身和形容事物的資訊能被區別

在網路上關於真實世界事物的資訊 文件 URI

Document URI

這些命名了位於網絡上的文件,這些文件由每個辨識碼統一資源識別元的發佈者清楚地連接,以提供關於真實世界事物的資訊。
表示 URI

Representation URI

當一個文件URI提供超過一個格式,每一個格式可分別以表示URI來命名

基於格式,有些表示URI可命名機器可讀的文件,且因而可提供進一步關於命名資源的連結

每一個識別碼在一個集合中的索引 列表 URI

List URI

這些提供辨識碼URI的列表,其包含在一個集合中
概念的定義 知識本體 URI

Ontology URI

鑑於一個真實世界事物識別一個事物的個別實例,這是需要提供概念的定義,而知識本體URI可被查詢以提供定義。

 

事物間的關係 知識本體URI

Ontology URI

一個RDF宣告的每一部份可以使用URI來命名,這包含真實世界事物之間的關係。

 

而知識本體URI給予一個到知識本體的連結,可以提供關係和及其所關連的概念的進一步推理。

URI集合

URI Set

URI集合 是指參考資料以URI發佈的參考資料URI之集合,一個URI集休也是表達一個概念,由單一資源來管理,例如,學校公路、司法都是各自的集合

命名URI集合且可以被所解析以提供這個集合品質特性之辨識碼 URI的一個型態

 

該報告由既存的優良實作經驗中衍生且經由修改而導出一些符合UK公部門URI集合原則,如表2所示。

表2: URI設計原則

原則
使用HTTP所以URIs可以被解析 必要
使用固定路徑結構以明確指示出URI的型態 建議
URI集合是否被提升被政府或公眾的其它部份再使用,發佈者會把它弄的更清楚 必要
公部門URI集合應該發佈他們期待壽命和對於再使用的潛力 必要
這些被提升為再使用的公部門URI集合應該至少可維持10年 建議
如果超過有一個代表URI,提供一個文件URI其中內容協商(Content Negotiation)可以用來提供最合適的表示 建議
避免暴露在一個在URI結構中的技術實現(implementation) 建議
至少提供一個機器可讀的表示URI 必須
如果適當,提供一個人可以的URI在HTML中 建議
對於單一文件URI提供發現每一個可用的表示URI的方法 建議
一個URI集合會發佈它的授權、身份驗証、和使用共同語彙的資料品質特徵 必須
一個URI結構不會包含任何會改變的,例如session IDs 必須
一個URI路徑結構是可讀的,以致於人對於它的內容會有合理的了解 建議

 

報告中也提供了當公部門要建立URI集合時的原則和考量,如表3。

表3:  公部門要建立URI集合的原則和考量

原則 考量
負責真實世界的事物的部門或機構應該負責定義URI集合和命名URI集合的實例,合適部門的代表 URIs應該被組織進具有領頭部門或構機的部門

領頭部門/機構應該與利益關係人接觸以確保這集合是能足以符合廣泛的需求

從一個被提昇為再使用的集合的URIs不應該包含現正負責它的部門或機構之名稱 這涉及到政府部門的改變,一部門或機構可以停止或改變業務範圍
圖1: URIs整合到集合之概念圖

一個URI集合可以包含4個部份(如圖1):

  1. 一個命名集合和描述它的品質特徵的URI
  2. 在單一概念中,對於真實世界事物的每一個識別碼URI
  3. 選擇性的,定義綱要的概念和關係的知識本體URI
  4. 選擇性的,列出在集合中的識別碼URI的列表URI

基於上述的定義和原則,該報告提出各個URI類型的案例,如表4所示。

URI 類型 URI結構 案例
識別碼 http://{domain}/id/{concept}/{reference}

or

http://{domain}/{concept}/{reference}#id

http://education.data.gov.uk/id/school/78 http://education.data.gov.uk/school/78#id http://transport.data.gov.uk/id/road/M5/junction/24
文件 http://{domain}/doc/{concept}/{reference} http://education.data.gov.uk/doc/school/78
表示 http://{domain}/doc/{concept}/{reference}/{doc.file-extension} http://education.data.gov.uk/doc/school/78/doc.rdf
綱要概念的定義 http://{domain}/def/{concept} http://education.data.gov.uk/def/school
綱要識別碼列表 http://{domain}/doc/{concept} http://education.data.gov.uk/doc/school
集合 http://{domain}/set/{concept} http://education.data.gov.uk/set/school

 

下圖則是顯 示URI如何被解析,例如http://transport.data.gov.uk/id/road/M5 即代表的是M5高速公路,而http://transport.data.gov.uk/doc/road/M5 則是關於M5高速公路的資訊。

圖2: URI如何解析的案例

 

對於鏈結資料(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資料,無論在類別或屬性都有標準或既有的語彙,是可以考慮多使用這些語彙。

連結感測器資料(Linked Sesnor Data): 從氣象測站到連結資料

緣起

會進行這個Linked Sesnor Data的試作有一些緣由,把時間拉回2013年8月1日在環保署召集的「環境資源資料開放專家諮詢會議」,開會目的除了討論環保署資料開放平台,更是在於討論紫外線測站資料來當開放資料五顆星的範例。太酷了! 環保署願意進行開放資料5顆星的示範是一件很棒的事! 不但有助於環保署所屬開放資料品質的提昇,也可以刺激其它政府部會對於開放資料品質的關注。但會中業務單位所簡報的那個「紫外線測站的五顆星開放資料」是問題多多,對於OWL/RDF有了解的人,其實不難發現簡報中的那份RDF是有問題的,況且把資料編譯為RDF格式充其量就是4顆星等級,怎麼可以說是5顆星呢?再者,所謂的5顆星開放資料是要連結什麼呢!?

這個問題後來成為與會專家要給予的答案。資料集與資料集要連結,這之間就必需要有某一些關連,也就是所謂的context,以致於資料集中的某一個entity可以與另一個entity以某種形式相連,在普遍的做法就是用owl:sameAs來表達在不同資料集中的二個entity是一樣的,以我有限的所知,資料集之間的context可以由三個特性來思考: 地理空間(Geospatial)、時間的(Temporal)、和主題屬性的(Attributiive),以環保署開資料平台中的紫外線測站資料為例,有可能連結的部份看來只有地理空間的特性了! 就資料特性而言,若環保署要做Linked Open Data (LOD),建議應該朝向Linked Sesnor Data,就是把所有測站以OGC的Sensor Web Enablement (SWE)W3C SSN Ontology 二者來表達環保署中的測站,而測站所產生的資料則是以Linked Observation Data 來詮釋。

 

IMG_20140103_121214從Sesnor nodes組成sensor network,然後以OGC SWE來架構Sensor Web,所以容易再以W3C SSN Ontology表達

 

IMG_20140103_121156Linked Sesnor Data, Linked Observation Data, and Geonames

 
很遺憾的是,他們並沒有採納這些意見,在環保署開放資料平台上線後,12月初無意間看到,那個有問題的說明己經在環保署開放資料5顆星的頁面上,而有問題的RDF資料也提供下載。這種做法給了二個不好的示範,首先,在專家會議中,本人就不認為那是對的說明和對的RDF資料,但這些內容和資料還是上線了,好吧! 意見也給了,那專家會議的用意什麼? 另一個是比較嚴重的問題是,把錯誤的LOD說明和資料放在一個政府公署開放平台的網頁上,很容易就會誤導其它人,對於LOD的理解,開放也得開放「對」的資訊,是吧! 身為市井小民所幸可以透過平台「意見回饋」反應機制,向環保署說明,那份說明的LOD頁面和RDF資料有問題,哈! 意見回饋比專家會議有效耶! 環保署在一週後拿掉在資料開放平台上的那些LOD資料,所以大家己經看不到了,接著承辦這項業務的人員也來拜訪,並帶著修改的RDF來討論。的確,修改後的RDF,使用了標準語彙,如Dublin Core,但看起來就是一份單純由表格轉為RDF的文件,這不見得有錯,但語意的表達是相當弱的,對於紫外線測站詮釋,也就是紫外線測站所表達出的概念是什麼?並沒有辦法得知。

或許,你心中油然而生一個問題,「疑!那些LOD的資料,在網頁看起來都像是表格一樣,那資料轉成這樣有什麼問題?」嗯! 那些LOD的資料背後其實都有一個ontology來表達資料的語意,只是放上網頁為了瀏覽方便而表現成表格的形態,利用標準語彙也是在確保資料語意不被誤解,但ontology中,概念的結構和邏輯的規範可以使資料語意更為完備,並可以進一步達到邏輯推理,當然目前我們只需要達到將資料本身概念充份地表達,在這個紫外線測站的案例中,如同前面所說,還是採用W3C SSN Ontology來表達紫外線測站才是比較恰當的方式。

從建構知識本體(ontology)開始

這筆所謂的紫外線測站基本資料所記述的資料相當有限,主要項目如下:

  • 紫外線測站的中英名稱
  • 紫外線測站所在的縣市鄉鎮
  • 紫外線測站的空間座標和住址
  • 紫外線測站的發佈機關

這筆有限的資料能表達出的內涵確實不多,若只根據這些項目編出的ontology應該也很空洞,對於一個用來表達紫外線測站的ontology而言,不僅僅是要表述地理空間的描述,更重要是要表達什麼是紫外線測站和紫外線測站觀測什麼。根據W3C SSN Ontology 對於感測器(Sesnor)的描述和定義,可以重新想想,要如何重新表達這筆紫外線測站資料:

  • 紫外線感測器本身是用來測量紫外線(Ultraviolet)的
  • 紫外線觀測是以紫外線指數(UV Index)
  • 紫外線感測器是裝在中央氣象局的氣象站或環保署的空氣監測站
  • 無論是氣象站或空氣監測站都有空間座標、地址、和所在行政區域

W3C SSN Ontology 這份報告附有很多案例是可以依循的,其中對於Linked Sesnor Data 就有一個案例,對於紫外線測站資料,不就是一個很好拿來模仿的案例! 對於感測器(Sesnor)的描述和定義,這個案例中主要使用W3C SSN ontology和DUL(DOLCE Ultra Light) ontology,此外也描述感測器(Sesnor)觀測能力和裝在氣象局的事實,更重要的是這樣表達的感測器(Sesnor)是可以被連結(link)。根據這個架構,可以設計一個ontology來解釋這筆紫外線測站資料,而這個ontology 不單單只有紫外線測站的ontology,而應該是感測器知識本體(sesnor ontology),且可以應用在任何不同的感測器上,我習慣先用畫圖把需要的class和individuals先勾勒出來,以便後續ontology的編輯。

uv_ontology根據W3C SSN 和 DUL設計的紫外線感測器ontology

 
與寫程式類似,ontology的編輯可以用文字編輯器,但也有一些工具輔助,一般常用的工具為Protégé,根據上面那個畫好的圖,這個UV sesnor ontology 很快就能完成。
 

Linked Data: 讓自己可以被連結,也可以連結別人

一一解釋UV Sesnor Ontology中類型(class)和個體(individual)會是冗長的說明,為了有效率的說明UV Sesnor Ontology中的知識表達,以下是擷取部份段落來做解釋:
 

Solar501A (亂瞎掰的)感測器本身是用來測量紫外線(Ultraviolet)的,安裝於台北氣象站的系統平台上,且有量測紫外線指數(UV Index)的能力,而紫外線指數有15個等級,每一個等級就是100焦身/每平方公尺,例如8就是測到紫外線800-899焦身/每平方公尺。紫外線指數又可以分級為低量級、中量級、高量級、過量級、和危險級,下面案例只顯示紫外線指數8-10是過量級。

 

###  http://lod.tw/ontologies/weather-station/uv#Sensor_Solar501A

:Sensor_Solar501A rdf:type ssn:SensingDevice ,
                           owl:NamedIndividual ;

                  ssn:onPlatform :Platform_for_Taipei_Weather_Station ;

                  ssn:hasMeasurementCapability :UV_Index_MeasurementCapability .

###  http://lod.tw/ontologies/weather-station/uv#UV_Index_MeasurementCapability

:UV_Index_MeasurementCapability rdf:type ssn:MeasurementCapability ,
                                         owl:NamedIndividual ;

                                ssn:inCondition :UV_Sacle ;

                                ssn:forProperty :Ultraviolet .

###  http://lod.tw/ontologies/weather-station/uv#Ultraviolet

:Ultraviolet rdf:type ssn:Property ,
                      owl:NamedIndividual .

###  http://lod.tw/ontologies/weather-station/uv#UV_Sacle

:UV_Sacle rdf:type ssn:MeasurementRange ,
                   owl:NamedIndividual ;

          ssn:hasValue :UV_Index_0_interval ,
                       :UV_Index_10_interval ,
                       :UV_Index_11_interval ,
                       :UV_Index_12_interval ,
                       :UV_Index_13_interval ,
                       :UV_Index_14_interval ,
                       :UV_Index_15_interval ,
                       :UV_Index_1_interval ,
                       :UV_Index_2_interval ,
                       :UV_Index_3_interval ,
                       :UV_Index_4_interval ,
                       :UV_Index_5_interval ,
                       :UV_Index_6_interval ,
                       :UV_Index_7_interval ,
                       :UV_Index_8_interval ,
                       :UV_Index_9_interval .

###  http://lod.tw/ontologies/weather-station/uv#UV_Index_8_interval

:UV_Index_8_interval rdf:type DUL:Region ,
                              owl:NamedIndividual ;

                     :hasMeasurementPropertyMaxValue :UV_Index_8_max_value ;

                     :hasMeasurementPropertyMinValue :UV_Index_8_min_value .

###  http://lod.tw/ontologies/weather-station/uv#UV_Index_8_max_value

:UV_Index_8_max_value rdf:type DUL:Amount ,
                               owl:NamedIndividual ;

                      DUL:hasDataValue "8.99"^^xsd:float ;

                      DUL:isClassifiedBy :Hecto_joule_per_square_meter .

###  http://lod.tw/ontologies/weather-station/uv#UV_Index_8_min_value

:UV_Index_0_min_value rdf:type DUL:Amount ,
                               owl:NamedIndividual ;

                      DUL:hasDataValue "8.0"^^xsd:float ;

                      DUL:isClassifiedBy :Hecto_joule_per_square_meter .

###  http://lod.tw/ontologies/weather-station/uv#Very_High_Risk

:Very_High_Risk rdf:type ssn:FeatureOfInterest ,
                         owl:NamedIndividual ;

                rdfs:label "過量級"^^xsd:string ;

                ssn:hasValue :UV_Index_10_interval ,
                             :UV_Index_9_interval ,
                             :UV_Index_8_interval .

 

台北氣象站的系統平台是台北氣象站的一部份,台北氣象站是中央氣象局的一部份,而台北氣象站和中央氣象局都是一種組織(Organization)。

 

###  http://lod.tw/ontologies/weather-station/uv#Platform_for_Taipei__Weather_Station

:Platform_for_Taipei__Weather_Station rdf:type ssn:Platform ,
                                               owl:NamedIndividual ;

                                      ssn:attachedSystem :Sensor_Solar501A ;

                                      DUL:hasLocation :Site_Taipei_Weather_Station ;

                                      DUL:isPartOf :Taipei_Weather_Station .

###  http://lod.tw/ontologies/weather-station/uv#Taipei_Weather_Station

:Taipei_Weather_Station rdf:type :Weather_Station ,
                                 owl:NamedIndividual ;

                        rdfs:label "Taipei"^^xsd:string ,
                                   "台北"^^xsd:string ;

                        DUL:isPartOf :Central_Weather_Bureau_Taiwan ;

                        DUL:hasLocation :Site_Taipei_Weather_Station .

###  http://lod.tw/ontologies/weather-station/uv#Weather_Station

:Weather_Station rdf:type owl:Class ;

                 rdfs:subClassOf DUL:Organization .

###  http://lod.tw/ontologies/weather-station/uv#Central_Weather_Bureau_Taiwan

:Central_Weather_Bureau_Taiwan rdf:type :Government_Organization ,
                                        owl:NamedIndividual ;

                               rdfs:label "中央氣象局"^^xsd:string .

 

台北氣象站是在台北氣象站場址(site),這個場址是一個地方(Place),有一個WGS 84 XY座標的參考點(reference point),且這個場址有一個地址(Address),這場址也在一級行級行級區的台北市之中和二級行政區的大安區之中,且大安區也在台北市之中,而台北市在台灣之中。

 

###  http://lod.tw/ontologies/weather-station/uv#Site_Taipei_Weather_Station

:Site_Taipei_Weather_Station rdf:type DUL:Place ,
                                      owl:NamedIndividual ;

                             geo:hasGeometry :Reference_Point_Taiepi_Weather_Station ;

                             vcard:hasAddress :Address_Taipei_Weather_Station ;

                             :is_in :Daan_District ;

                             :is_in :Taipei_City .

###  http://lod.tw/ontologies/weather-station/uv#Reference_Point_Taiepi_Weather_Station

:Reference_Point_Taiepi_Weather_Station rdf:type geo:Point ,
                                                 owl:NamedIndividual ;

                                        wgs84_pos:long "121.55834"^^xsd:float ;

                                        wgs84_pos:lat "22.036934"^^xsd:float ;

                                        geo:asWKT "Point(121.5583420000, 22.0369330000)"^^sf:wktLiteral .

###  http://lod.tw/ontologies/weather-station/uv#Address_Taipei_Weather_Station

:Address_Taipei_Weather_Station rdf:type owl:NamedIndividual ,
                                         vcard:Address ;

                                vcard:street-address "公園路64號"^^xsd:string ;

                                vcard:locality "台北市"^^xsd:string ;

                                vcard:country-name "台灣"^^xsd:string ;

                                vcard:region "大安區"^^xsd:string .

###  http://lod.tw/ontologies/weather-station/uv#Daan_District

:Daan_District rdf:type lodtw:2nd_Administration ,
                        owl:NamedIndividual ;

               :is_in :Taipei_City ;

               owl:sameAs freebase:Daan District ,
                          geonames:Daan District .

###  http://lod.tw/ontologies/weather-station/uv#Taipei_City

:Taipei_City rdf:type lodtw:1st_Administration ,
                      owl:NamedIndividual ;

             :is_in :Taiwan ;

             owl:sameAs freebase:Taipei ,
                        geonames:Taipei ,
                        wikidata:Taipei ,
                        depedia:Taipei.

 
眼尖的你不難的不發現,上述的每一個「類型(Class)」和「個體(individuals)」都是以URL方式呈現,如http://lod.tw/ontologies/weather-station/uv#Taipei_City; 且上一段中的台北市和大安區都己經以owl:sameAs分別連結到DBPediaGeonamesWikidata、或Freebase,如UV sesnor ontology中的Taipei_City是以owl:sameAs連結http://rdf.freebase.com/ns/m.0ftkx, http://sws.geonames.org/7280290/, http://www.wikidata.org/entity/Q1867, 和http://dbpedia.org/resource/Taipei。與一開始所做的分析一樣,在這筆資料中地名是最有可能拿來連結其它資料的實體(entities)。

最後,想強調的是,編寫這個UV Sesnor ontology用意在於讓更多人了解什麼是LOD,並期待能引發更多LOD的討論,而能有更多更正確的LOD資料。

鏈結資料 (Linked data)、開放資料(Open Data)和鍵結開放資料(Linked Open Data): 從學術到產業行與不行?

昨天應「高人」之邀,參與了台北市電腦公會舉辦的第三場 Open Data產業新契機系列論壇,會中的提問,好像講了太多我們過去的做LOD的經驗,但我提出問題的可能不是很精確,所以台上沒有任何回應,會後也沒有進一步的討論,只有台北市議會的人,是周柏雅議員的助理嗎? 說如果台北市的資料有這樣的問題我們可以幫你,感恩啦! 因為說的不好,所以在自己的部落格上解釋一下。我的發言應該是這樣的

本人在LOD上有實作,有一些經驗可以分享。研考會陳怡君科長說得好,政府資料中有74%是與地理資料有關,地理資料的開放與LOD的發展有很大的關係,今天就以地名而言,是一個很好的鍵結資料,如大家知道「野柳」過去被西班牙人稱為Diablo,這就是同一地點在不同時間上的對於地方稱呼的鍵結,也是台灣與西班牙的鍵結,地名資料目前是沒有公開授權的資料庫,中研院生物多樣性中心和農委會林試所,已經就利用他們所建立的4 5個資料庫中的資料透過開放授權,將資料釋出後,再以LOD技術與全球資料庫GBIF鍵結,並上傳到datahub.io被審核後成為LOD cloud的一雲,而我以內政部地名資料為主,做了另一個LOD的資料集已經與全球最大的地名資料庫Geonames.org 連結,並沒辦法完全上傳至datahub.io,原因是台灣地名資料庫沒有公開授權,若我上傳即有法律上責任,目前只能以學術研究方式提供參考。

(發言的內容有做過一些修飾,但大意沒變。哈哈哈,當天下午已經是疲憊不堪,在沒有充足的提精飲料下,實在無法完整的想起來我說了什麼。TCA的人在我發言完後,拿了一張紙來叫我把我的發言寫下來,幹嘛!這是小學生考試嗎?TCA的大哥大姊別欺負我,請看上面不精確的回憶)

我的問題要表達一件重要的事情,資料沒有公開授權怎麼有辦法做LOD,若要說也只是Linked Data不是Linked Open Data,我長年關心的是地理資料開放授權議題,都到現在這個節骨眼上了,總不能還叫廠商花錢買? 但在場的人似乎不是很在乎這件事。

接下來,對於LOD在產業上的發展,有些觀察,因個人研究興趣,對於語意網和鍵結資料有一些經驗,但三年多來對於鍵結資料的研究,多是都在學習歐美國家發展的狀態,本身並沒有研發出了不起的理論或軟體,相信一定有人比我還專業,能夠說得上的,獻醜了,就是去年在一個日本舉辦的國際會議上,就如何利用LOD資源來做強化非結構性資料,讓使用者在Facebook上貢獻資料中的能夠與現存的LOD資料相連,發表了一篇文章,論文集會由LNCS出版,有興趣可以看看投影片內容

然而這一趟去了日本,學習不少,讓我驚豔的地方是日本對於Open Data的推動方式。學術團體、地方政府和民間業者共同推動Linked Open Data (LOD) Challenge,使得產官學能夠以Open Data的需求與供應面上,就資料集(Data set)、想法(idea)、應用程式(Application)、視覺化(Visualization) 等四個面向來做競賽,個人對於這個活動做了一個簡單的介紹,而觀察了幾個月下來發現,這樣子的競賽活動快速帶動政府、產業和學術的相互交流,強調的是Open Data資料真正落實資料應用的發展、從個人收集女性流行服飾資料並做成APP,到利用政府公開資料來發展生態或深度旅遊應用程式,對於Open Data的應用上,就廣度和深度都有一定的水準。

學術上的研究本來就應該落實到產業,但學術研究的人並不一定能夠了解產業的需求,藉由一次次名為“Challenge”活動,實際上是一種「溝通與對話」,可以逐步地媒合資料供給、技術研發和產業發展,TCA舉辦一系列論壇的目的和日本LOD Challenge相同嗎?老實說,在昨天的論壇中,我沒有看到LOD真正能夠落實到產業是什麼?先不論技術層面的問題,資料連不連的起來的問題,就「原住民族文化觀光資料開放」中的幾個Use cases,看起來就只是在消費原住民的文化,是以治理(或統治)者的角色在思考產業,但這或許是原罪,現存資料庫中的資料本來就是以治理者角度在建立資料,而不是保存文化的角度,舉一個簡單的例子,傳統領域可能與觀光不是那麼密切,但傳統原住民的地名,用他們自己語言來謂呼的地方的名字,是一個重要的文化資產,各位到蘭嶼,下飛機後,看到的地圖是漢語不是達悟族語,那他們為什麼不能用達悟族語來表達他們的地名?同樣的,玉山、雪山和許多高山可能都有布農族或泰雅族地名,為什麼沒有一個漢語和原住民語,雙語併行的地圖? 若原民會手上有原住民傳統地名,拿來和內政部地名Link一下,往後觀光業者就這個資料開發,就可以有雙語,可以行銷在地,又可以教育民眾在地知識,保存原民文化,(長官~,我希望看到的這樣的案例)。廣告一下,事實上,有一群長期關心原民文化的朋友(而且還有外國人參與,汗顏!外國人比我們還關心原住民),長期在花東一帶做原住民語輸入法,也逐步地將原住民語地名建入OpenStreetMap。

LOD的發展是技術面很吃重的工作,若要以推廣LOD進入產業,工具的研發或在化地是很重要的一環。目前在歐洲多是以歐盟層級的大型計畫,如FP7中的LOD2來做研發,並釋放許多的Open Source工具,使後續可以就他們的經驗和基礎再研發。但有許多工具,不一定適合於台灣的資料,最簡單,我們使用的是中文,和別人語系不同,在處理語意,和資料鏈結也會不同,(腦海中竟然出現肝藥廣告詞:成份不同、效果也不同),工研院扮演的角色是針對原民會的這個計畫研發工具,並釋放給業界使用? 昨天的簡報和問答,實在沒有辦法了解到這點。

LOD是達到開放資料五顆星等級的方法,是世界潮流與趨勢,很高興,政府單位開始想做著手做這部份,舉雙手贊同。但昨天聽起來,心中疑惑更多,這樣的討論充其量的只是一個Linked Data的論壇,而不是Linked Open Data的論壇,這麼多被提到資料,有多少是開放授權呢? 再者,談LOD進入產業是否太早,工具研發和人才培育是關鍵,我很懷疑目前台灣有多少技術人才可以進行LOD的工作,產業若要接手有多少工具可以使用?多少人才可以運用? 如果這二個基礎都沒有,LOD產業可能只是另一個空談。

 

 

語意技術聯合國際研討會 (Joint International Semantic Technology Conference, JIST 2012)

JIST2012是第二屆,上一屆在中國杭州,如果沒有搞錯這個研討會的前身應該是ASWC (Asian Semantic Web Conference)。

JIST2012

雖然這是亞洲區語意網會議,但參加的人不僅來自於亞洲國家,除了日本、韓國、中國、泰國、越南、印度、伊朗、台灣,許多人是來自於歐洲,如德國、英國、愛爾蘭、瑞典、芬蘭、義大利、盧森堡,少數來自於美洲,如美國和加拿大,來參與的人不乏是語意網領域有名的單位組織,如愛爾蘭的DERI (Digital Enterprise Research Institute)、美國的Kno.e.sis Center in Wright State University、德國的 University of Leipzig、日本的NII (National Institute of Informatics)、韓國的KISTI、中國上海交通大學、清華大學,參加人數約100人左右。

會議內容雖有少數偏於理論, 但多數論文偏於語義網和資料連結的實務性研究,4個邀請演講也偏向於應用面,以業界的實務應用,詳細內容可參考議程 。與會的人多為語意網或連結資料方面專家,尤其能在亞洲地區的會議遇到這麼多來自歐美地區且是語意網的專家,三天的會議下來,彼此互動切蹉,獲益良多,有些沒想過研究主題,衝擊腦袋,產生不一樣且具體的想法 。

我們的論文有幸被接受並口頭發表。此行 另一個收獲是能夠了解日本在Open Data和LOD的推動和做法,在JIST 2012 大會的前一天LOD Challenge社群舉辦的International Asian LOD Challenge Day,雖然來不及參與這一天的活動,但後來有機會與LOD Challenge社群接觸,並了解一些日本在推動Open Data和Linked Open Data 的做法和推動方式,這一些觀察整理成 LOD Challenges

相較而言,JIST的等級當然比不上ISWC和ESWC,但被接受的文章仍然有一定的水準,但接受率略高,約在36-37%左右。詳細的接受率為:

  • Regular papers 22/58
  • In-Use track papers 7/17
  • Special track papers 6/15
  • Linked Data in Pratice 4/11
  • Database Integration 2/4