G20農業鏈結開放資料會議 Part 1 – 會議背景和Keynote

會議背景

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農業資料的關鍵。

接續 Part 2。

英國政府公部門的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) 之方向去努力
  • 增加獨特的價值: 建立在你有但別人沒有
    • 挑出你可以解決的問題
    • 帶入你所處的機構/社群來思考
  • 對於鏈結資料結構、可取得的知識本體和你的資料能有好的理解
    • 消化你所發佈的資料
    • 一開始就考慮法律授權問題
    • 盡量廣泛地參考相關資料且諮詢專家
  • 現在開始! 就去做吧!

鏈結農產品產銷履歷資料(Linked Traceability Agricultural Product Data)

食品安全是現今社會的課題,歐美日等先進國家為確保食品安全,已先後實施食品「可追蹤系統」(Traceability System),而食品可追蹤系統應有二個方向,一為向上溯源(從下游往上由追查),二為向下追蹤(從上游往下游追查),二個方向的追蹤應都可追查食品在生產、處理、加工、流通、販賣等各階段的資訊。也就是說, 在食品生產、加工處理、流通販賣等各階段中,關於食品的進貨對象和銷售通路等記錄都予以妥善保管,並透過識別號碼的使用,使食品在各階段之產銷資訊能相互連結,進而建構出可以追溯或追蹤產銷資訊的體系,以在農產品而言,生產階段記錄農藥及化學肥料等栽培管理資訊,在加工階段,將原材料資訊等生產者或加工製造者所要傳達的資訊、將消費者需了解的資訊詳加記錄保管並發佈,以建立可供追溯或追蹤產銷相關訊息的體制 (胡忠一,2006)。台灣自2007年開始推動的農產品產銷履歷驗證制度,結合食品可追溯性(Traceability)和良好農業規範 (GAP)驗證制度,除了可追溯或追蹤產銷資訊,且具有採取嚴密驗證體系,以此建立飲食安全的基礎,並提升國產農產品的國際競爭力,創造農產品的附加價值(周念陵,2012),而可追溯性的建立,在食品安全事件發生時,可以讓主管機關、認驗證機構及相關業者,精確釐清危害來源, 並且快速回收問題食品,有效降低傷害(胡忠一,2006)。

農產品產銷履歷是一個關於農產品從這是一個從田間到零售、從生產者到消費者的記錄,包含產地、產品(作物)、生產者、通路商、栽種流程、加工流程、驗證等資訊,資料若能透過語意網技術加以精煉整理,資料本身可以展現許多知識,例如,作物之物候特性和栽種知識,據此知識,可以了解當令農產品,幫助消費者選擇,若農產品產銷履歷能與農情統計資料連結,一方面,生產者可以了解農產品的生產趨勢,商品流動狀態,因此可以訂定栽種策略,另一方面,政府則可進行作物宏觀的管理、制定作物栽種的調控策略,以免作物大量栽種,在市場崩盤,再進一步,若作物資料可與既有的生態資料庫連結,如植物資料庫,以建立長期生態農業的基礎環境。

然而,資料集與資料集之間的最基本的連結是透過主鍵(Primary Key),一般而言,就是一組不重複的唯一識別碼(ID),但以鏈結資料(Linked Data)而言,只要是資料集與資料集中有相同的實體(entity),就應該相互連結起來。相同實體在不同資料集間的連結是智慧化的開始,透過不斷地連結使得描述實體的內容愈來愈多,以作物名稱為例,作物名稱會被使用在產銷履歷中,但沒被區分出來,一旦區別出來,可與農產品批發市場交易行情中的作物名連結,而了解市場價格,這樣的過程就像是用同一作物名稱同時查詢二個資料庫再把資料整合,但同一作物有可能有不同名稱,同一名稱有可能不同作物,舉例而言,我們常吃的高麗菜,在農產品批發市場交易行情中是使用甘藍菜,鏈結資料即是把這二個作物名稱對映,機器處理資料時能透過這樣的連結而處理更多的資料,而這種連結若不斷持續的擴展,即可建立出知識圖(Knowledge graph)。

除了相同實體連結外,對於機器而言,實體的內涵,及其所代表的一種概念,都應該被清晰的解釋,在人的閱讀過程,可以將知識組合,但對於機器而言,這些實體若沒有清晰的定義,機器是沒辦法區辨出實體所代表的含意及其關係,以致於機器沒有提供進一步的有「智慧」的服務,因此,農業資料的鏈結建立,需要從實體的語意層級的定義開始,也就是建立與定義農業資料語彙,進一步地,建立農業知識本體(ontologies),並調查國際上已發展的農業詞彙,研究如何和這些詞彙映對,以擴展在地農業知識與全球的整合。

建立鏈結資料的目的在於提供一個更完善的資料基礎設施(data infrastructure),以便讓資料在不同知識領域的服務系統或資料庫中的流動,減少人為處理,並且疏理出更多知識脈絡,進而找出資料治理(data governance)的策略,因此農業鏈結資料的發展在資料基礎 設施的脈絡下,是可以增加不同知識領域或不同利益關係者的互操作性(Interoperability)和協同合作(collaboration),因而提昇公私部門協同合作的效率和生產力。

本研究利用農委會產銷履歷之開放資料,建立產銷履歷知識本體,及其三元組儲存庫,並利用該成果建立應用示範,本案朝向於如何利用語意化的產銷履歷資料提供智慧化的服務,讓使用者在瀏覽食譜過程中,有一智慧化元件利用語意化的產銷履歷資料自動地推薦產銷履歷農產品要去那裡買,或者可以去那家餐廳吃到使用產銷履歷農產品的料理。

資料與方法

為了說明如何建立利用語意化的產銷履歷資料的智慧化元件,以可以自動化推薦使用者產銷履歷農產品的服務,本節利用情境案例的方式說明該元件可以達成的服務,及建立該智慧化元件所面臨的問題和解決方法。

情境案例(use case)

小娟是一個家庭主婦,當她開始準備晚餐時,來到了iCook瀏覽蕃茄炒蛋的食譜,如圖1所示。在瀏覽食譜時,小娟可以透過一個瀏覽器上「外掛元件」的服務,找到該食譜網頁中食材所相對應的產銷履歷農產品,以及販賣產銷履歷農產品之賣場和餐廳,並利用簡單的邏輯和空間運算,可以找到在離小娟住家最近的商店,以便購買。在前往購買之前,小娟透過該元件的服務,了解該農產品的價格,估算做這道菜的成本。對於同一種農產品可能有很多的選擇,該元件後端系統整併了產銷履歷達人的資料,因此可以推薦小娟產銷履歷達人的農產品。因為食安問題,販賣產銷履歷農產品之賣場和餐廳是否為合格廠商亦是被關心的問題,衛福部食藥署之登錄的食品業者,該外掛元件後端系統將販賣產銷履歷農產品之賣場和餐廳與衛福部食藥署之登錄的食品業者先進行比對且連結,因此可以提供小華欲前往之賣場是否為衛福部食藥署已登錄的食品業者。

圖1: 在iCook中的蕃茄炒蛋食譜

問題與分析

情境案例中的「外掛元件」,可以利用JavaScript去建立Chrome瀏覽器擴增模組(extension),讓使用者在瀏覽食譜網站時,不需要跳出本來瀏覽的食譜網頁,而這個外掛元件基本上應該進行二件工作,一是讀取iCook食譜網頁中食材,二是以食材送出查詢以取得產銷履歷農產品,以及販賣該產銷履歷農產品之賣場與餐廳,並提供條件設定,可過濾不符合條件之結果。由這二件工作中,我們列出問題,並藉由分析問題中提出解決的方式。

(1) iCook食譜網頁中的食材如何清晰地被取得?

iCook網頁中使用schema.org的語彙,如圖2所示,蕃茄炒蛋中的食材,如牛蕃茄、蛋、青蔥、鹽、…等,都以schema:ingredients 這個語彙所釋詮,因此Chrome的外掛在設計上可以利用Schema.org的語彙,以避免在語意的模糊,而可以清晰地的取得食材。

圖2: iCook網頁中使用schema.org的語彙

(2) 產銷履歷農產品資料雖然已使用結構化的資料儲存方式(JSON),但資料中的實體,如作物名稱、銷售通路商、混雜在文字之中,如何被區分出來?

產品名稱中通常會夾雜作物名稱,如圖3中的產品名稱「檸檬-產銷履歷檸檬(產銷履歷檸檬)」夾雜著「檸檬」,再者,銷售通路中,也夾雜著商店名,如「惠康Wellcome超市(全台各分店), …」這一項中提到,頂好、愛買、家樂福、全聯、好市多等商店,但全在一個欄位,進一步地,「全台各分店」是指這商品在該商店的全台每一家分店都有買,就資料的語意而言,應該區分至每一家分店。

圖3: 產銷履歷農產品開放資料的JSON格式

(3) 產銷履歷農產品、產銷履歷農產品之賣場與餐廳、產銷履歷農產品達人、衛福部食藥署之食品業者登錄分屬不同資料集,資料結構亦不同,如何透過語意技術達到跨資料集的查詢?

產銷履歷農產品、產銷履歷農產品之賣場與餐廳、產銷履歷農產品達人、和衛福部食藥署之食品業者登錄之建立並不是同一個資料集,以關連式資料庫的基礎的傳統做法,是將所有資料透過主鍵的方式將資料串連,而語意網的做法,則朝向於聯合式SPARQL查詢,此查詢得以進行,是因為RDF資料集中,已經先將語意相同的事實相互連結,或以owl:sameAs語彙對映,因此SPARQL查詢過程中,以圖形(graph)為主的三元組資料(RDF),可以整合在一起,以提供完整的結果。

當然,產銷履歷農產品、產銷履歷農產品之賣場與餐廳、產銷履歷農產品達人、和衛福部食藥署之食品業者登錄等資料需要以三元組資料(RDF)方式編碼,且以知識本體為基礎,並分別建立SPARQL查詢端點(endpoint)。

(4) 產銷履歷農產品和產銷履歷農產品之賣場與餐廳中只有地號地址沒有XY座標,如何過濾結果?

產銷履歷農產品和產銷履歷農產品之賣場與餐廳之資料中只有地號或地址,為了進行空間查詢與運算,必需把地號和地址轉化為經緯度坐標。所幸內政部TGOS中有提供地址轉經緯度坐標的服務,且Google Maps亦提供地址轉經緯度坐標之服務。地籍地號方面,地政司也有地籍查詢便民系統,可查詢地籍之經緯度坐標,但無提供API查詢,本研究則是使用社群所建立的地籍地號轉座標的API 達成轉換,可透過這二個系統來取得空間座標。

技術與方法

農產品產銷履歷資料是開放資料,但產銷履歷農產品之賣場與餐廳、和產銷履歷農產品達人只公開在網頁上,但尚未以開放資料釋出,本示範案會設計網頁爬蟲,以自動化抓取這三個網頁中的內容。

取得資料後,需要清理資料,並利用自然語言處理,例如具名實體辦認(Name Entity Recognition),來區分出實體。藉由實體所表達概念與關係,建立知識本體,並利用W3C在語意網的規範,例如,OWL和RDF來編碼三元組資料,且儲存三元組於三元組資料庫(triple store),以及三元組資料服務端點(SPARQL endpoint) 。

而衛福部食藥署食品業者登錄已是開放資料,農產品產銷履歷之銷售通路商和餐廳有許多應是已登錄的食品業者,再者,這些銷售通路商也應該可以在經濟部商業司的公司登記資料中查詢的到,然而,這三者的商店或公司名稱常所指的是同一家公司,但名稱卻不一致,需要自然語言處理,找出相同的銷售商名稱和餐廳,待找出相同的實體後,利用owl:sameAs對映。

圖4: 具名實體辨識處理的示意圖

自然語言處理

具名實體辨識(Named Entity Recognition)是一種從一組文字中區分出具有意義之人事時地物名稱的自然語言處理方法,此方法將文字斷字的處理後,判斷單字會在句子之中出現的特定位置,根據文法結構,單字被分類至所屬的預設的分類,如人名、組織名、地方名、時間、數量、百分比、貨幣…等,圖3所示 。再者,為了對映二資料中相同的實體,如作物名稱,也需要字串相似度的比較 方法。

知識本體

本體論(Ontology)一詞是由亞里斯多德(Aristotle)在 Metaphysics IV, 1 中所提 出,為哲學之一個分支,是研究「 在」本身的問題,即一切現象事物的基本特質。哲 學家所探討的問題著重在於「 在是什麼?」、「 在的特徵是什麼?」和「 在所歸類 的共同特徵是什麼?」等一系列形而上學的問題。然而,本研究中的「知識本體」 (Ontologies)一詞,並非在哲學領域的討論,而是資訊工程中用來定義資料本身語意 (Semantics)的方法,Guarino(1998)為了區分哲學和資訊科學中的知識本體不同, 建議哲學領域所使用的知識本體為英文大寫單數的專有名詞 Ontology,而資訊科學所使 用的知識本體為英文小寫複數一般名詞 ontologies,也就是說,將知識本體(Ontologies) 視為資訊的一種。
而知識本體的的建立即是知識工程,是知識呈現的技術與方法,Noy and McGuinness(2001)認為建立知識本體應該定義

  1. 知識本體中的類別(Classes);
  2. 安排分類體系中的類別(Subclass–Superclass);
  3. 定義屬性(Slot)和描述這些屬性的允許值;
  4. 給實例(Instance)填入屬性的值。

就知識工程的方法,他們認為知識本體的建立應包含三個步驟:

  1. 定義領域和範圍;
  2. 考慮重覆利用性;
  3. 列舉本體中的詞;
  4. 定義類別和層級;
  5. 定義屬性;
  6. 重新定義屬性;
  7. 建立實例。

Gruber(1995)提出用框架和第一階邏輯(First Order Logic)來建立知識本體,並定義 5 種基本要素:類別(Classes)、關係(Relations)、功能(Functions)、正規的原則(Formal axioms)和實例(Instances)。而知識本體(Ontologies)根據表達方式有不同的正規化 (Formal)程度,如果表達成自然語言,知識本體可以是高度非正規的;如果表達在一個限制和結構的自然語言形態中,則是一個半非正式的; 如果表達在人工和正規定義的 語言,如 RDF 和 UML,是一個半正規知識本體,而如果一絲不苟地以正規的屬性的語意(Semantics)、定理(Theorems)和證據(Proofs)來定義知識本體中的詞,則是 一個完全正規的知識本體,如第一階邏輯(Uschold and Gruninger,1996; Gómez-Pérez et al.,2004)。隨著,語意網技術的發展,W3C已製定了知識本體的語言OWL(Web Ontology Language) ,其中使用描述性邏輯(Description Logic) 來定義語意,目前大多數知識本體的建立皆以 OWL 為主,只是在格式上採用較為簡單的Turtle或N3。而知識本體的建立工具則以Protégé 為最多人使用。

三元組儲存庫

原始資料透過知識本體,將資料轉化為RDF格式,若是原始資料為表格型態(spreadsheets)可以用Google Refine的 RDF擴充模組、XLWrap、RDF123、或NOR2O等工具,若資料是關連式資料庫,則可以D2RQ、 ODEMapster、或W3C RDB2RDF WG 所發展的R2RML等工具。而若是 XML格式,則可以使用GRDDL或ReDeFer。
資料轉為RDF後,必需由三位組資料庫(triple stores)來儲存, 將RDF資料處理後, 以便提供查詢與管理,因為RDF的查詢語言為SPARQL,因此提供於網路上提供 SPARQL來查詢和管理RDF的接口,又稱為SPARQL端點(endpoints),目前已經有許多開源的工具可以使用,如Jena、Virtuoso、Sesame、4Store、OWLIM、和BBN Parliament等,而為方便RDF資料在網頁上瀏覽,且可以直接透過網頁展示連結資料,目前也有數套前端連結資料服務的工具可以使用,如Pubby, TalisPlatform、Fuseki、和D2RQ等,值得注意的是Pubby和D2RQ是二個受歡迎的前端連結資料服務,但其資料處理與提供方式並不相同,D2RQ強調資料儲存於關連式資料庫中,透過turtle格式映對(mapping)編輯,D2RQ可以直接將關連式資料庫中之資料轉為RDF,並直接顯示於網頁上,而Pubby的後端則必需接上一個三位組資料庫來提供資料。

SPARQL查詢

SPARQL為RDF的查詢語言,其設計的概念很像關連式資料的查詢語言SQL。為展現圖型式資料集和鏈結資料的好處,本案使用聯合式(federated) SPARQL查詢來建立前端的示範平台,為說明聯合式SPARQL查詢,本案利用Andreas Schwarte (2011) 的投影片來解釋,如圖5所示。

圖5: Federated SPARQL Query示意圖

RDF是一個方向性的、標籤的圖型(graph)資料,向來表達在網路中的資訊,SPARQL可以用來表達跨不同資料來源的查詢,其中資料需要是RDF或以RDF做為中繼的媒介,聯合式的(Federated) SAPRQL Query 也是一個W3C所 倡議的標準 之一。圖6為聯合式的SPARQL查詢之範例,其查詢跨過二個資料集,或者說二個SPARQL Endpoints,欲查詢紐約時報報導美國總統的頭版文章,透過DBpedia,可以找到美國總統,如圖6 所示,這些被找到的美國總統,則可以對映到紐約時報中總統,紐約時報所用的語彙只是總統,並沒有說明是那一個總統,但因為利用sameAs指向了DBpedia,因此,機器知道在紐約時報找到的這個Barack Obama總統,是美國總統,如圖8所示,聯合式的(Federated) SAPRQL可以一直利用這種方式查找下去,並找到更多的總統,及其報導文章,如圖9所示。

圖6: 聯合式的SPARQL查詢的範例
圖7:先找出DBpedia中的美國總統
圖8:利用owl:sameAs對映所找的美國總統
圖9:對映出更多的美國總統

系統架構

根據問題分析和技術方法的討論,本案預計以聯合式SPARQL查詢方式建立Chrome擴增模組,以提供產銷履歷農產品的應用示範,其系統架構如圖10所示,除了第一期所建立之產銷履歷農產品之三元組資料及SPARQL查詢系統(endpoint),本案會另建立產銷履歷農產品之賣場與餐廳、產銷履歷農產品價格、衛福部食藥署之食品業者登錄、和經濟部商業司工商資料庫等五個資料集之三元組資料及及查詢系統(endpoint),其所有空間參照也都將利用內政部的服務系統轉化成經緯度座標,以便空間條件的查詢過濾。整體而言,系統的運作方式,如圖11所示。

圖10: 系統架構圖
圖11: 系統運作

資料擷取與清理

產銷履歷農產品賣場資料的處理

於農產品產銷履歷網頁上,可查尋到賣場的資料,如圖12所示,且開放資料平台亦釋出「產銷履歷供需資訊-找通路」,這資料集只有8筆資料。根據農產品產銷履歷網頁上的賣場資料,大約可以得到300多筆賣場資料,但這些資料並不完整,因此,本案是以農產品產銷履歷JSON資料中,在「StoreInfo」所提到的商店名稱,該欄資料中包含了大量連鎖商店,如圖3中,惠康Wellcome超市(全台分店),因此先透過網路爬蟲將所有連鎖商店之分店資料擷取,如名稱、地址,若一農產品產銷履歷產品是記載供貨到「惠康Wellcome超市」,則該農產品產銷履歷產品是對映到頂好的全台所有分店,而不是只是記載惠康Wellcome超市。而該欄中常只有農民名稱和連絡方式之銷售通路,這部份不納入整理,主要原因沒有住址無法定位,而在本案平台中展示。最後,將所有資料一一清理並整理成銷售通路資料庫,圖13所示。

圖12: 產銷履歷銷售通路

 

圖13: 產銷履歷銷售通路資料庫

產銷履歷農產品餐廳資料的處理

由產銷履歷農產品供貨資訊網站中,「那裡吃」可以取得使用產銷履歷農產品的餐廳的資料,餐廳的食材溯源又分為台灣農業跨領域發展協會和有心肉舖子所建之平台,如圖14和圖15所示,二者要呈現的資料都是餐廳有那些餐點使用了產銷履歷農產品,但網頁結構不同,因此需要設計二個爬蟲程式去捉取資料。最後,整理成使用產銷履歷農產品餐廳資料庫,如圖16所示。

圖14: 有心肉舖子所建立的有心溯源餐廳平台
圖15: 台灣農業跨領域發展協會所建立的溯源餐廳系統
圖16: 使用產銷履歷農產品餐廳資料庫

產銷履歷達人資料的處理

每年的產銷履歷手冊都會把獲獎的產銷履歷達人的採訪和資料整理刊出,如圖17,而這些再被產銷履歷農產品資訊網中一則一則分出來,提出PDF檔,如圖18所示。因產銷履歷達人筆數目前不多,本案是以人工方式逐一整理,成為資料庫,如圖19所示。

圖17: 獲獎的產銷履歷達人
圖18:產銷履歷農產品資訊網中的產銷履歷達人
圖19:產銷履歷達人資料庫

衛福部食藥署食品業者登錄之處理

通路商和餐廳整理好之後,利用自然語言處理,自動地去比對產銷履歷中的通路商名稱和衛福部食藥署食品業者登錄中公司的名稱,計算其字串的相似度,因名稱常有重複,再者再以地址輔助來判斷是否為同一商家。在地去比對產銷履歷中的通路商名稱對應到衛福部食藥署食品業者登錄的公司後,可取得統一編號,利用統 一編號可串連經濟部商業司公司登記。

三元組資料與應用系統

知識本體的建立

為清楚解釋農產品產銷履歷資料,知識本體的設計分為三個部份,產地之地理空間、農業概念、和產銷關係,如圖20所示。在產地之地理空間方面,是以「產地 (Place of Origin)」為基礎,每一個「農產品產銷履歷 (Traceable Agricultural Product)」都透過「產於(isProducedAt)」指涉一個「產地 (Place of Origin)」,其產地則是由一個「地址(vCard:Address)」或一塊「農地(Parcel)」來表示,地址表達是再利用vCard的語彙,則可以轉換成「點(geo:Point)」,重複利用OGC GeoSPARQL語彙來表達,農地是一個圖徵概念(geo:Feature),實際上是指涉到一個地號,而地號可以轉換成「點(geo:Point)」或「多邊形(geo:Polygon)」,同樣是使用OGC GeoSPARQL語彙來表達。無論是「點(geo:Point)」或「多邊形(geo:Polygon)」都是幾何的概念(geo:Geometry),也都有geo:WKTLiteral來記錄經緯度資料。

就農業概念而言,「農產品產銷履歷 (Traceable Agricultural Product)」是一個相等於AGROVOC語彙中的農產品(agrovoc:Agricultural Product),該農產品是產品的子類別,而每一個「農產品產銷履歷 (Traceable Agricultural Product)」中都可以區別出一種「作物(Crop)」,該作物概念也同等於AGROVOC語彙中的「作物(agrovoc:Crop)」,該作物是植物的子類別,也就是植物的一種,雖然農產品和作物都是簡單的概念,若沒有充份、有邏輯的解釋,機器是沒有解讀其語彙的語意,本研究所設的知識本體並不需要「重覆製造輪子」,利用農業專業領域中所製定的國際標準語彙,即可將概念充份解釋,讓機器解讀。

同樣的,在產銷關係方面,本研究所設計的知識本體則是利用Friend-Of-A-Friend語彙(簡稱foaf),每一個「農產品產銷履歷 (Traceable Agricultural Product)」都會有一個「驗證單位(Certification Agency)」、「通路商(Store)」、和「農產品經營業者(Producer)」,這三個概念都可歸納成foaf中的「組織(foaf:Organization)」,而每一個「農產品產銷履歷 (Traceable Agricultural Product)」也都有一個「生產者(Farmer)」,該生產者是foaf中的「人(foaf:Person)」。此外,每一個「農產品產銷履歷 (Traceable Agricultural Product)」也具有一個XML schema格式之整數值的追蹤碼、一個XML schema之日期格式的包裝日期、和一個XML schema日期格式之驗證有效日期。

圖20: 農產品產銷履歷知識本體

三元組資料的轉換與資料查詢端點的建立

本研究是透過D2RQ將農產品產銷履歷資料轉換為三元組資料(triplify),且發佈三元組資料。D2RQ Server是用來發佈關連式資料庫內容在語意網上的一個工具,語意網即是一個包含鏈結資料的全球資訊空間,為達到鏈結的資料,資料需要被模型化且表達成三元組的編碼,D2RQ Server使用客制化D2RQ映對語言(mapping language)來對應資料庫內容和三元組資料編碼,並且可以讓這些三元組資料被瀏覽和透過SPARQL語言查找,這二個方式都是語意網開放近用(access)的典範。

三位組儲存庫(triple stores)是來儲存、管理、查詢RDF資料集的平台,而RDF的查詢語言為SPARQL,因此提供於網路上提供SPARQL來查詢和管理RDF的接口,因此,利用三元組儲存庫來提供SPARQL服務的平台,又稱為SPARQL端點(endpoints),目前已經有許多開源軟體的工具可以使用,如Jena、Virtuoso、Sesame、4Store、OWLIM、和BBN Parliament等,而為方便RDF資料在網頁上瀏覽,且可以直接透過網頁展示鏈結資料,目前也有數套前端鏈結資料服務的工具可以使用,如Pubby、TalisPlatform、Fuseki、和D2RQ等,值得注意的是Pubby和D2RQ是二個受歡迎的前端鏈結資料服務,但其資料處理與提供方式並不相同,D2RQ強調資料儲存於關連式資料庫中,透過turtle格式映對(mapping)編輯,D2RQ可以直接將關連式資料庫中之資料轉為RDF,並直接顯示於網頁上,而Pubby的後端則必需接上一個三位組資料庫來提供資料,如圖 21所示。

圖21:D2RQ和Pubby之比較

D2RQ平台包含三大部份,分別是D2RQ 映對語言(D2RQ Mapping Language)、D2RQ 引擎(D2RQ Engine)、和D2RQ 伺服器(D2RQ Server),如圖22所示。映對語言是一種敘述性映對語言,用來描述知識本體和關聯式資料庫的資料模型之間的映對關係。D2RQ 引擎是Apache Jena 的外掛模組(plug-in),Jena API是接受SPARQL語言接口,而這個外掛模組即是用來重寫來自於Jena API的SPARQL語言查詢為SQL語言,使得查詢得以在關聯式資料庫中運作,另一方面,也將在關聯式資料所查詢的結果,轉成RDF資料,使得關聯式資料庫成為三元組儲存庫的使用,因此也可以透過這個外掛模組將關聯式資料庫中所有的資料,以RDF的格式倒出,或者再與其它JAVA的應用程式一起使用。D2RQ 伺服器則是一個HTTP的伺服器,提供鏈結資料的以HTML的方式瀏覽、查核RDF資料的正確性、和提供SPARQL的查詢。

圖22:D2RQ平台架構
圖23:產銷履歷農產品的D2RQ server

D2RQ Server是依靠映對檔將資料庫中的資料轉化成為三元組資料,進 一步地可將三元組資料顯示於網頁中,使資料可以容易用瀏覽器閱讀。為實現鏈結資料,本案將產銷履歷農產品、通路商、和餐廳三個資料集 ,分別建立SPARQL Endpoint,圖23即是產銷履歷農產品的D2RQ server,運作於 http://tap.linkedopendata.tw 上,包含作物(Crop)、生產者(Farmer)、產銷履歷達人(Expert)、 農產品經營業者(Producer)、產品名稱(Product Name)和產銷履歷農產品(Traceable Agriculture Product)等類別,除了瀏覽HTML和RDF資料的功能,D2RQ server亦提供SPARQL的查詢。

完整的映對檔在附錄中,此章節只解釋重點關鍵的宣告表達方式,圖24即顯示本研究所設計的映對檔中的一段,對於「產品名稱 (tap:ProductName)」和「產銷履歷農產品 (tap:TraceableAgriculturalProduct)」二個類別(class)映對定義。在「產品名稱 (tap:ProductName)」類別(class)的定義中,第一段中說明了產品名稱本身被化為唯一的URL(urlify),如「http://tap.linkedopendata.tw/page/ProductName/小白菜(履歷)是唯一的,第二段中宣告了資料庫中產品名稱欄位的值並用於產品名稱的標記(label)。

但還是有許多產銷履歷農產品名為為「小白菜-履歷小白菜」,因此第三段宣告了所有具有相同產品名稱的產銷履歷農產品都歸於同一產品名稱,為確保唯一性,利用產品名稱和產銷履歷農產品的追蹤碼產生雜湊值(hash)來做為產銷履歷農產品的URL,確保產銷履歷農產品的唯一性,然後,再宣告這些具有相同名稱的產銷履歷農產品為產品名稱的「成員」(tap:member),如圖25 所示。

# Class ProductName
map:ProductName a d2rq:ClassMap;
d2rq:dataStorage map:database;
d2rq:uriPattern "ProductName/@@agricultureProduct.ProductName|[email protected]@";
d2rq:class tap:ProductName;
#d2rq:condition "";
#d2rq:classDefinitionLabel "ProductName";
.
map:ProductName_label a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:ProductName;
d2rq:property rdfs:label;
d2rq:pattern "@@[email protected]@";
.
map:ProductName_member_TraceableAgriculturalProduct a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:ProductName;
d2rq:property tap:member;
d2rq:uriSqlExpression "CONCAT('http://linkedopendata.tw/tap/resource/TraceableAgriculturalProduct/', cast(MD5(CONCAT('Name:', agricultureProduct.ProductName, 'Tracecode:',agricultureProduct.Tracecode)) as char))";
.
#Class TraceableAgricultureProduct
map:TraceableAgricultureProduct a d2rq:ClassMap;
d2rq:dataStorage map:database;
d2rq:uriSqlExpression "CONCAT('http://linkedopendata.tw/tap/resource/TraceableAgricultureProduct/', cast(MD5(CONCAT('Name:', agricultureProduct.ProductName, 'Tracecode:',agricultureProduct.Tracecode)) as char))";
d2rq:class tap:TraceableAgricultureProduct;
.
map:TraceableAgricultureProduct_label a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:TraceableAgricultureProduct;
d2rq:property rdfs:label;
d2rq:pattern "@@[email protected]@";
.
map:TraceableAgricultureProduct_tracecode a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:TraceableAgricultureProduct;
d2rq:property tap:hasATracecode;
d2rq:column "agricultureProduct.Tracecode";

圖25: 映對檔中定義「產品名稱 (tap:ProductName)」和「產銷履歷農產品 (tap:TraceableAgriculturalProduct)」二個類別(class)的一部份

第四段是宣告「產銷履歷農產品 (tap:TraceableAgriculturalProduct)」類別的映對,第五段是宣告產銷履歷農產品之標記(label)是使用資料庫的的欄位,第六段是宣告「產銷履歷農產品 (tap:TraceableAgriculturalProduct)」類別的屬性(property),這段所描述的是產銷履歷農產品具有一個追蹤碼。產銷履歷農產品的其它屬性的宣告方式與追蹤碼宣告方式相似,完整的映對檔可以參考附錄。

圖26:產品名稱「小白菜(履歷)」所具有的「產銷履歷農產品」之成員(tap:member)
圖27: 產品名稱為小白菜(履歷)且追蹤碼為10601020580的產銷履歷農產品

圖27即顯示追蹤碼10511150594及名稱為小白菜(履歷)的產銷履歷農產品,其驗證單位、追蹤碼、農產品經營業者、通路商、產地、生產者姓名、包裝日期、驗證有效日期、詳細栽種流程、詳細履歷資料、詳細加工流程、和其他驗證資訊皆一一列出。與產銷履歷農產品和產品名稱同樣的處理方式,生產者也可以透過唯一辨別的URL和產銷履歷農產品相互指涉,如圖27中的生產者「蘇軍達」,透過蘇軍達的URL即可了解這個生產者產出多少產銷履歷農產品,如圖28所示。同樣地,由於所有的農產品履歷中的事物皆已URL化,因此選擊「保證責任雲林縣漢光果菜生產合作社」的URL可以知道該單位所產出的農產品履歷,如圖29所示。

圖28:生產者「蘇軍達」所產出的產銷履歷農產品
圖29:農產品經營業者「保證責任雲林縣漢光果菜生產合作社」所產出的產銷履歷農產品

D2RQ平台提供SPARQL查詢,圖30顯示出產銷履歷農產品產地之查詢結果。

圖30: 產銷履歷農產品產地之SPARQL查詢

除了產銷履歷農產品的SPARQL endpoint,本研究亦建立通路商和餐廳二個SPARQL endpoint,分別在store.linkedopendata.twrest.linkedopendata.tw。在通路商的部份,如圖31所示,除了名稱、住址和經緯度坐標之外,經過名稱相似度比對後,利用owl:samaAs,連結衛福部食品業者登錄資料集,取得統一發票號碼後,再連結經濟部商業司公司登記資料,此外,從產銷履歷農產品資料中整理通路商和作物的關係,因此可以跨Endpoint,以通路商連結產銷履歷農產品,反之亦然。在餐廳的部份,如圖32所示,除了基本的名稱、地址和經緯度坐標,有使用的作物名稱,也有使用產銷履歷農產品的餐點。

圖31: 通路商Endpoint中的「家福樂板橋店」
圖31: 餐廳Endpoint中的「京華煙雲」

Chrome瀏覽器擴增模組的設計

Chrome瀏覽器擴增模組的建立容易,但核心其實是包含在其中JavaScript所執行的任務。RDFLib 是一套專為鏈結資料所設計的套件,其功能包含讀寫RDF資料、 在用戶端進行以SPARQL 讀寫Linked Data、解析 RDFa、建立在地端的查詢API、和處理owl:sameAs的結點,利用RDFLib,我們開發Chrome瀏覽器擴增模組「LinkedFood」。

iCook愛料理網站使用schema.org的語彙來編輯食譜,有利於資料的詮釋,LinkedFood即針對schema.org的語彙來設計資料的讀取,當LinkedFood擴增模組安裝後,開啟iCook的食譜時,LinkedFood即會自動地讀取到食材,透過讀 取的食材,LinkedFood則分別向產銷履歷農產品、通路商和餐廳的SPARQL Endpoint送出查詢,而得到RDF的三元組資料。當在LinkedFood的介面操作時,按了食材,後,在地端可在整合的RDF三元組資料進行查詢,如圖32所示,在那裡買的分頁中,按上方的食材後,如蕃茄,在下方地圖會顯示有賣這個食材的商店,同樣的,如圖33所示,也可以顯示出有那個餐廳可以吃到產銷履歷農產品,利用twfood.cc網站中所整理的價格資訊、產量、以及綜合二種資訊所得到的推薦指數,可以提供使用者購買的參考,如圖34所示,而食材所涉及的每一項產銷履歷農產品,可以在LinkedFood中的最後一個分頁瀏覽,如圖35所示。

圖32: Chrome瀏覽器擴增模組「LinkedFood」的那裡買
圖33: Chrome瀏覽器擴增模組「LinkedFood」的那裡吃
圖35: Chrome瀏覽器擴增模組「LinkedFood」的產銷履歷瀏覽
圖34: Chrome瀏覽器擴增模組「LinkedFood」的推不推

整個Chrome擴充模組的操作可見Youtube影片。

參考文獻

  1. 周念陵(2012),健康美麗產銷履歷,行政院農業委員會。
  2. 胡忠一(2006),建立我國農產品產銷履歷紀錄制度,安全農業生產體系研討會專集,13~40頁

TGOS不進化嗎?! 從ISO 19115到GeoDCAT的鏈結資料

就目前國際潮流而言,為方便地提供開放資料,許多政府紛紛建立資料平台讓人民可以取得開放資料,基於分散式管理的概念,多數政府資料平台的架構不僅是一個資料儲存庫(Data Repository),也是一個資料目錄服務(Catalog Service),在此系統架構下,資料本身並不一定得要儲存於唯一的資料平台,而分散地儲存於各資料平台中,但資料集的銓釋資料可以彼此交換,讓使用者透過一個資料平台即可瀏覽和查詢到所有資料,因此銓釋資料能提供愈完整的資訊,則使用者能在資料平台找到所想要的資料之機會愈高。

在詮釋資料在開放資料平間交換的部份,開放資料管理平台CKAN,一套廣為被許多國家開放資料平台所使用的開源軟體,其中「資料採集(Harvest)」的模組支援了由其它平台收存銓釋資料的功能,此模組本身因整併pycsw套件,因此可處理ISO 19115標準的詮釋資料,並可將地理資訊平台發佈的標準詮釋資料,自動地搬移到CKAN的開放資料平台,而美國開放資料平台(data.gov)即是採集了過去美國聯邦政府的地理資料平台(GOS)中的目錄資料,而將地理資料目錄整併進開放資料平台,此外,CKAN也支援W3C資料目錄語彙 DCAT (Data Catalog Vocabulary) 的採集。

隨著開放資料平台的增加,因應資料目錄的交換,使用標準銓釋資料於開放資料的需求因而隨之增加,銓釋資料遇到的問題不僅在於多個平台,且是不同類型的釋銓資料之管理。基於各知識領域的使用方式,可能都存在各自的銓釋資料標準,如地理空間資料是以ISO 19115為銓釋資料標準、電子化政府資料和圖書資訊資料是以都柏林碼(Dublin Code)、而生態資料是以生態銓釋資料語言(Ecological Metadata Language)做為標準,因此英國愛爾蘭數位企業研究所(Digital Enterprise Research Institute, DERI) 在2010年左右建立了「資料目錄語彙」(Data Catalog Vocabulary, DCAT),被先W3C 電子化政府同好群(eGov Interest Group)納入討論並修改,最後被政府連結資料工作群(Government Linked Data working group) 標準化,於2013年被W3C發佈為標準。

在DCAT於開放資料平台的應用方面,相較於英美而言,歐盟的投入較為極積,這是因為歐盟的開放資料平台需要整合來自各國所提供的開放資料,為解決資料在於跨平台的互操作性問題,歐盟在2013年即發展出DCAT應用綱要(Application Profile),就而空間資料而言,歐盟空間資訊基礎設施(INSPIRE) 要考量的不只是各國地理空間資料的整合,還有地理空間資料與其他類型資料的相容性問題,他們相對積極地企圖以DCAT來整合各國資料平台之內容,並對映地理資訊銓釋資料標準(ISO19115/19119)和DCAT語彙,而發展出以地理空間資訊為主的資料目錄GeoDCAT。2015年5月 聯合國全球地理資訊管理委員會(UN-GGIM)在葡萄牙里斯本舉行的專家會議中,對於統計資料和地理資料的連結之問題中,提出以利用DCAT的解決之道,也就是將統計資訊銓釋資料標準 (SDMX) 和DACT對映,並推導出StatDACT,加上GeoDACT,讓二項釋詮資料的描敘都是以DCAT為核心,但保留對特定領域資料的描敘,使DCAT成為一個大架構來整合二種不同性質資料的想法(UNGGIM, 2015)。

圖1: DCAT語彙之UML關係圖 (Source: https://www.w3.org/TR/vocab-dcat/)

DCAT是一個RDF語彙,用來使發佈於網路上資料目錄能夠達到資料的互操作性,DCAT為W3C的銓釋資料標準,利用DCAT 在語彙描述資料集,可以使應用程式能容易地消化不同知識領域的銓釋資料,並使資料發佈者增加所發佈資料集在網路中被尋找可能性,再進一步地,DCAT可使資料目錄的發佈更為去中心化,促進跨平台的聯合式(federated)資料集搜尋的可能。DCAT語彙 包含三個主要類別(classes),如圖1,分別為dcat:Catalog, 用來表達一整個資料目錄; dcat:Dataset, 用來表達一目錄中的資料集; 以及,dact:Distribution 用來表達資料集的可及性方式,例如以下載、RSS或網路服務的方式來提供資料集。另一個重要的類別是選填的,dcat:CatalogRecord 是用來描述一資料集在資料目錄中。DCAT、GeoDCAT和ISO 19115的對映與討論,可透過歐盟網站上文件來了解,並可設計一套轉換的程式,自動將本來為以XML編輯的ISO 19115語彙轉成RDF編輯的GeoDCAT,也就是將銓釋資料轉為四星級資料。

圖2‭: ‬TGOS資料「座標對位影像五萬分之一分幅地質圖‭ ‬‭(‬頭城‭)‬」之銓釋資料

圖3‭: ‬以平溪「火燒寮」在TGOS上無法查詢到相關圖資在這個ISO 19115語彙可轉換成GeoDCAT的語彙的條件成立下,接下來可以討論以ISO 19115為銓釋資料標準的TGOS,如何在四級星的開放資料下擴展為五星級的可能。以TGOS中「座標對位影像五萬分之一分幅地質圖 (頭城)」為例,其銓釋資料如圖2所示,這個案例著重於在這銓釋資料中二個的項目,分別是關鍵詞和圖資的空間範圍,如圖2所示,其空間範圍為:

最西經度值 gmd:westBoundLongitude:121.748481 ;
最東經度值 gmd:eastBoundLongitude:122.002055 ;
最南緯度值 gmd:southBoundLatitude:24.748512 ; 和
最北緯度值 gmd:northBoundLatitude:25.001564。

利用此一圖資的四極座標範圍,查詢地名資料庫,可得到177筆地名,涵蓋新北市的坪林區、平溪區、貢寮區、雙溪區、和宜蘭縣壯圍鄉、宜蘭市、礁溪鄉、頭城鎮,若這171筆地名皆成為該筆資料的關鍵詞,那TGOS在查詢資料時,則可以查詢到該筆資料,反之,則無法讓使用者利用地名,這種便於人們查詢地理資料的語彙,在TGOS中來查詢圖資料,如圖3所示,若以上述圖資四極座標範圍中的地名之一 「火燒寮」來查詢TGOS,其實無法找到相關圖資,但若是先前將圖資四極座標範圍和地名,或相關資訊做一關連後,再補充該筆資料的銓釋資料,則可增加資料被查詢到的可能性與向度。 此外,可以接續地名連結資料的處理,以達成TGOS資料的五星級。

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

WordNet-Similarity Installation

This logs my installation of WordNet Similarity.

The current version of WordNet::Similarity is 2.0.7, released on October 4, 2015. The install file in source code explains the installation well, however, some little problems occur with new Mac OSX, e.g. Sierra.

The WordNet-Similarity 2.0.7 works with the other packages:

  • WordNet-3.0
  • WordNet-QueryData-1.49
  • Text-Similarity-0.13

WordNet-3.0 needs to be installed firstly, and then the other two packages. Although WordNet 3.1 can be installed via Brew, my case is not successful to make WordNet 3.1 working with WordNet-Similarity 2.0.7.

As the installation of WordNet, a issue was occurred from the step of ‘make’ in stubs.c. The following is the error message.

stubs.c:43:17: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result =
~~~~~~ ^
stubs.c:55:14: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result = bitfieldstr;
~~~~~~ ^
stubs.c:72:17: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result = “usage: bit bitnum”;
~~~~~~ ^
stubs.c:78:14: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result = bitfieldstr;
~~~~~~ ^
stubs.c:92:17: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result =
~~~~~~ ^
stubs.c:105:14: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result = resultbuf;
~~~~~~ ^
stubs.c:117:17: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result = “usage: glosses [1 | 0]”;
~~~~~~ ^
stubs.c:132:17: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result = “usage: fileinfo [1 | 0]”;
~~~~~~ ^
stubs.c:147:17: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result = “usage: byteoffset [1 | 0]”;
~~~~~~ ^
stubs.c:162:17: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result = “usage: senseflag [1 | 0]”;
~~~~~~ ^
stubs.c:178:17: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result = “usage: contextualhelp partofspeechnum searchtypenum”;
~~~~~~ ^
stubs.c:183:14: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result = helptext[pos][searchtype];
~~~~~~ ^
stubs.c:193:17: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result = “usage: reopendb”;
~~~~~~ ^
stubs.c:207:17: error: no member named ‘result’ in ‘struct Tcl_Interp’
interp -> result = “usage: abortsearch”;
~~~~~~ ^

Google the issue. I found a solution from StackOverflow. One suggestion is modify the line using ‘interp->result’ to ‘Tcl_SetResult’, e.g.

from

interp->result = "usage: glosses [1 | 0]";

to

Tcl_SetResult(interp, "usage: glosses [1 | 0]", TCL_DYNAMIC);

After the modification, do configure and make again. WordNet 3.0 can be successfully installed. (You type wn in terminal for testing if the WordNet installation is successful).

With having WordNet 3.0, the WordNet-QueryData-1.49, Text-Similarity-0.13, and WordNet-Similarity 2.0.7 are installed well via following procedure:

  1. perl Makefile.PL
  2. make
  3. make test
  4. su
  5. make install
  6. exit

To test if WordNet-Similarity 2.0.7 is installed successful, you can go to the folder ‘samples’, and find sample.pl. Then, try ‘perl sample.pl cat#n#1 dog#n#1′. You will see the result like the following screenshot.

screenshot-2016-10-15-12-09-22

All functions of WordNet-Similarity 2.0.7 are in the folder ‘utils’. If you’d like to launch a web service of WordNet Similarity, you can use similarity_server.pl. Just execute it. Then, you can see as following screenshot.

screenshot-2016-10-15-12-21-40

2016年歐洲資料論壇(European Data Forum 2016)與會記行

1.歐洲資料論壇的背景

歐洲資料論壇(European Data Forum, EDF) 是每年一次的會議,聚焦在以資料為主的多個面向,如社會、經濟、研究、工程、和科學等,並著重於歐洲的資料趨動經濟之提昇,該會議自2012年起開始舉行,是由歐盟執委會(European Commission)中,連結的數位單一市場(Connected Digital Single Market)計畫下主導,但會議行政管理是由歐洲各國產官學相關人士組成指導委員會來執行,以確定每年會議主題與內容、目標、及預算支配,且評估歐洲各國提出舉辦會議的申請。

這二年的主題都以資料經濟(Data Economy)為會議主軸,來貫穿4個主題,

  • 巨量資料(Big Data),如何利用新的科學和工程方法,有意義的處理大量資料,
  • data_economy開放資料(Open Data),如何透過跨部門資料整併,以支援決策制定,提昇政府治理的透明度,
  • 鏈結資料(Linked Data),如何將鏈結資料技術與方法做為普遍的資料整合平台,
  • 由資料產生的價值(Data-driven value),由前三者去審視資料能產生的價值,並研析資料趨動經濟的方法和工具。

而基於數位經濟和數位化社會(Digital Economy and Society)的發展,會議本身也關注三個面向的發展,

  • 技術面,如何駕馭現今如此大量的、異質的、和動態的資料,面對這樣的資料世代,科技和基礎建設會是什麼樣貌?
  • 應用面,因為開放資料、鏈結資料、和巨量資料的快速發展,可能的新產品和服務會是什麼?
  • 社經面,在這個新的資料世代中,社會衝擊、法律問題、政府政策法規、商業模式、和創新方式的改變會是什麼?

歐洲資料論壇(EDF)是一個聚集歐洲各國的產官學人士,共同討論資料趨動創新的機會與挑戰的重要會議。所謂的資料趨動創新的機會與挑戰是著重在資料的基礎設施、工具、應用程式的發展潛力,及其所面臨之問題,因此資料趨動創新特別重視創新所可能帶來的社會和經濟面的影響。EDF這個會議所企圖吸引的參加者,是涉及資料價值鏈中的利益關係者(stakeholder),無論是從巨量資料技術方法之應用到創新想法的突破,或者是,各項進行中之政策的辯論到前瞻思維的演講中獲得啟發,在EDF中的意見與想法的交換,是會議的價值,這將為歐盟各國在未來資料經濟之研究課題的設計,和政策決定的方向上帶來影響,這即是推動資料趨動創新往前動力,強化歐洲資料經濟的力量,也是奠定歐洲資料經濟在全球地位的基礎,因此這屆的EDF將主軸定為 Scaling up the European Data Economy,換句話說,資料經濟的議題在歐盟並不是新的開始,而是進入到擴大並強化各個領域在資料經濟的應用規模。

By Rijksdienst voor het Cultureel Erfgoed, CC BY-SA 3.0 nl, https://commons.wikimedia.org/w/index.php?curid=37243214

本屆的歐洲資料論壇(EDF)是由荷蘭埃因荷芬科技大學(Eindhoven University of Technology )中資料科學中心(Data Science Center Eindhoven (DSC/e)) 肩負起主要籌辦的角色,因此會議舉辦城市即在荷蘭埃因荷芬,該城市即是一個工業城,是許多知名企業的根據地,如菲利浦、NXP、ASML…等,值得一提的是城市行銷是以Brainport為主題,有別於鹿特丹的海港和阿姆斯特丹的空港,所謂的Brainport即是集合整個區域的公司企業、大學、和研究中心,成為一個創新研發的城市,這樣的策略倒也很符合EDF主軸,是強調資料趨動的創新下的經濟動能。

而會議場館Evoluon則是一個很特殊外觀的建築物,這個飛碟造型的場館是原本是當地的科學館,在1966年就落成,已經有50年的歷史,後來成為菲利浦的會議中心。

2.會議內容

2.1.真槍實彈的鍵結資料應用

EDF2016會前有幾個工作坊和活動一同在Eindhoven舉行,巧好會議前一天(6/27)的早上看到有一個活動是荷蘭鏈結資料平台(Platform Linked Data Nederland)舉辦的荷蘭鏈結資料會議,在沒有事先報名的情況下就直接殺去會場,結果主辦單位很包容地讓我參加了會議,結果會議還沒開始就遇到老朋友,Simon Scheider,目前在烏特列支大學(Utrecht University)地理系任教,仔細一看,他上下午各有一個演講,一個是講的是地理資料在進行跨資料集連結時,如何除錯、確定地理實體的型別、正確的相互連結的工作流程,另一個是講鏈結資料和空間分析整合的潛力。更有趣的是,下午有一個講者居然是我的指導教授Rob Lemmens,他的演講是在介紹歐盟的一個計畫ENERGIC Project 中如何利用自願性地理資料進行Datathon,這真是太巧了!

其實會議中有一個案例很吸引我,講的是半導體企業NXP和Freescale合併時,產生資料整合的問題,雖然二個企業體都是做半導體,各自企業的資料架構是不同的,因此在企業整併的過程出現資訊系統整合的難題,為了解決這樣的困境,他們選擇使用鏈結資料的技術和方法來整併二家企業的資料,這個工作是由Semaku這家工公司承接,最後NXP和Semaku根據這樣的經驗建立了一個 NXP Enterprise Data Hub,這個鏈結資料的應用在去年接連拿到荷蘭鏈結資料應用的首獎和歐洲鏈結資料首獎

 2.2.企業善用資料,開創新商業模式

edf2016

由Keynotes的結構來看,這個會議確實是秉持產官學互動交流的原則,在8個Keynotes中有4個是來自於業界的分享,菲利浦總裁 Frans van Houten介紹自家許多家電產品已經收集消費者的使用行為資料,分析資料可以提供更好的服務,例如,電動牙刷利用藍芽和手機連結收集使用者的刷牙方式,若有使用者刷牙方式錯誤,手機應用程式可以自動提醒。西門子數位工廠部門工廠資料服務資深副總 Ralf Wanger則是介紹西門子賣出的機器中裝有感測器(sensor),可以消費者可以將機器連結上西門子的資料服務中心,系統可自動分析維修時間,並自動安排員工進行檢修。導航和地圖空間資料服務的知名公司TomTom之總裁Harold Goddijn 則是分享公司跨界轉型過程,單純買圖資或GPS導航的獲利已經不高,TomTom已將圖資應用在支援無人車研發。知名線上音樂公司Spotify,資料分析主任Andres Arpteg 以資料科學的角度來了解消費者使用行為,他們利用資料探礦的方法分析了解消費習慣以提昇音樂平台的服務。

第一天下午和第二天有三個時段各有三個平行的場次,主題分別是Automotive, Data-Driven Government, Agrifood, Urban Smart Living, Smart Industry,Novel Emerging Areas, Educations and Skills, Healthcare, 和 Media,這9個場次的講者來源,有政府官員、非營利組織、大學及科研中心,更有來自公司企業,不同領域在同一主題上所面臨的問題可能不一樣,但在同一個場所的討論則有助相互交流和經驗分享,與會者中有許多是來自於歐洲的中小型企業(SMEs),藉由研討的過程,他們有機會提供他們的技術與經驗和講者交流,也就創造他們參與大型計畫,以及和大型企業合作的機會。

2.3.政府部門主導資料經濟政策的制定img_0721

會議中有二個歐盟政府官員的Keynotes,都與EDF的組成有關,一個是來自歐盟執委會 在數位經濟和文化的專員,以錄影方式發表演說,另一個是Márta Nagy-Rothengass 歐盟網通科技總署 (DG Connect) 中資料價值鏈部門的主任,以「 Building a data-driven economy – The perspective of the European Commission」為題演說。

img_0722她的演講中清楚地勾勒出歐盟在資料政策上制定與推行,在多國組成的歐盟,不同制度文化下,資料的管理方式不同,造成資料整合應用上的障礙,一直是歐盟成立以來著重的問題,隨著開放資料、巨量資料和資料科學的風潮,歐盟也逐漸地在過去電子化政府運作中做出改變,開始著重於建立一個有效率的資料生態系統,朝向政府、科研、企業、公民等不同角色的公私部門夥伴(Public-Private Partnership)的合作架構,以促進資源與利益的共享、責任的共同承擔、並著重社會層面議題。

為了建立這樣的資料生態系統,開放資料的策略變得很重要,因為資料能開放地被近用,才有可能讓資料在不同的角色中相互流動,資料有流動就增加應用加值的可能性,在這樣的脈絡下,開放資料被視為資料經濟的一部份。因此歐盟不但極積的建立歐盟開放資料平台,2012年啟動,一開始只有歐盟本身的資料,去年(2015年)起開始要求各國開放資料匯入,另一方面也極積地調查歐盟資料市場的規模和潛力,透過歐盟經費補助,委由國際數據資訊(IDC)和Open Evidence 進行歐洲資料市場的調查,報告書在2015年發表,同時他們也建立了一個資料視覺化的工具,European Data Market Monitoring Tool,可瀏覽歐洲的資料市場情況。

2.3.學研機構提供資料治理的策略

img_0624
在Data-Driven Gvoernemnt場次中,JOHANN HÖCHTL 發表Performance-indicator based policy-making in Austria

會議中的展覽單位和參展海報中,不少是歐盟計畫的成果,如IQmulus,仔細調查可以發現,歐盟執委會在推動資料經濟,並不是單單只有制定政策,且提供許多經費給科研單位進行長期的研究,這些科研計畫是以解決問題為導向的研究,並重視跨國、跨領域間的協同合作,這些計畫過去也都參加過之前的EDF,在歐盟的網頁上可以看得到這些計畫

在Data-Driven Government場次中,有4個演講,除了論述政府如何應用資料治理的策略與方法,也包含了實務面的處理,荷蘭如何應用資料分析改善交通問題,奧地利如何運用開放資料制定指標以決定政策,法國如何透過培育計畫培殖更多資料科學人才。

fhg_193_ids_grafiken-eng-03Sören Auer是Fraunhofer IAIS 企業資訊部門主任,也是波昂大學企業資料系的教授,他在Smart Industry以Industrial data space digital sovereignty over data為題發表演說,提出 Industrial Data Space 是一個利用資訊標準和共同治理模式建構出一個虛擬的資料空間 ,這個構想之目的在於嘗試在商業環境中,讓資料的交換更安全且資料的連結更容易,這個構想想建立的系統也試圖提供一個基礎,以建立和使用智慧服務和創新商業流程,使得資料擁有者以確保他們的資料治理權 (digital sovereignty)。

透過使用情境,可以了解Industrial Data Space的架構和需求,這架構是在於創造資料價值鏈,以及調適以特定領域中鏈結資料的語彙以輕量化的語意表達,Industrial Data Space廣大地支援不同領域的情境,同時,也是下一代的工業生產 (工業4.0) 可以應用的範疇。此外,他也指出 Industrial Data Space 也是一個跨領域組織,包含商業、政府、和科研單位,於2014年底在德國成立,這個組織的目標清楚企圖建立一個歐盟、甚至是世界級的平台。

2.4.重視巨量資料科學研究、應用、與人才培育

EDF2016中二個Keynotes是來自於埃因荷芬(Eindhoven)附近的科研中心,分別是荷蘭提堡大學(Tilburg University)校長Emile Aarts和德國多特蒙德大學(TU Dortmund University)資料科學中心的主任Katharina Morik,他們各自介紹各自資料科學中心如何透過在企業合作以資料科學的方法解決問題,此外,也強調各自資料學中心的能力和潛力,以吸收更多人才的加入。加上埃因荷芬大學資料科學中心,似乎讓我有感覺有一個趨勢,就是這個過去以工業生產為主的區域,已經看清資料價值鏈中,傳統工業轉型後,所要扮演的角色,所以需要的人才,這些資料科學中心成為這個區域進入下一個工業世代的軍火庫,不但提供策略想法,也訓練人才。

3.會後心得

這次EDF的參與者有1070人,來自於48國家,參與人數最多的15國依次分別為,荷蘭、德國、比利時、英國、西班牙、希臘、奧地利、法國、義大利、愛爾蘭、匈牙利、挪威、盧森堡、芬蘭、萄葡牙等,有明顯的舉辦國優勢的傾向,以參與人員的行業類別而言,有40%是來自於工業界,32%是學術界、13%是公部門、和15%的其它,會議參與者多數是來自於業界,但科研單位的人也為數不少,這和我過去參與的學術會議巧好有點相反的情形,因此二天會議談論的事情,多是實務面的工作和面臨的問題,較少生硬的科學理論,相對而言,整體內容是比較能讓一般人進入的。

荷蘭North Brabant省的經濟經理Bert Puali,在會後的宣傳錄影中提到,「…在我們變得談論過多巨量資料的可能性之前,我們應該加入有執行力的那一方,藉由資料和資通訊相關的研究,以了解資料經濟的市場有多大…」,其實這就是EDF的主軸,整個會議雖然扣合歐盟「資料經濟」發展的政策,但不會讓人感到過多政策推動鑿痕,可以讓人感到的是,歐盟對於政策推動是根植於問題與挑戰的認知和了解,接著再提出解決問題的技術方法的一系列進程,反觀國內,通常把二件事情給壓縮了,常在政策推動的過程中,讓人看不清,解決問題的意識和方向是什麼? 而堆疊過多的技術名詞,沒有執行的實質內容,最後流於空洞。

在海報、展覽單位、以及與會會眾中,很多是資通訊產業的中小型企業(SMEs)的員工、甚至是老闆,試圖透過這個會議中尋找合作機會,這與歐盟資料經濟策略中重視中小型企業(SMEs)所扮演的角色有關,個人觀察,這就和公民科技在開放資料生態系中扮演重要角色是類似的,政府或大型企業在面對新問題和新挑戰時,由於組織體系的龐大,未必能及時適度確切的反應,而中小型企業較具有彈性,可以容易調整方向,調度人才,因此大型企業或政府單位和中小型企業合作,較能快速地解決問題,如之前提到NXP和Semaku的案例。

從許多EDF的演講中,可以發現有些研究是歐盟所補助的計畫,這些計畫無論是在智慧城市、物聯網或工業4.0上,都以資料為本,提出解決問題的架構、技術或方法,而這些計畫也不僅是單一科研單位所執行,而是跨國、跨領域協同合作,這種3-5年左右的研科計畫,也提供教育、研究資源,培養更多的人才,因此可以想像的,一個新興議題,如資料經濟,一開始大家都不熟悉,在這樣的情況下可以做出的策略自然保守且限縮的,而在補助科研單位的研究計畫中,利用博碩士生在深入研究推導,研究成果最終成為政府單位政策推動依據,這樣一個階段、一個階段的進行下,歐盟在開放資料、巨量資料、和鏈結資料逐漸形成策略,以面對不斷演變的挑戰,因此提出資料趨動經濟的論述,成為歐盟政策內容,形為今日如此的規模,這絕對不是把堆砌一堆技術名詞而缺乏解決問題方法的報告書重抄一遍,再重新包裝的政策內容。

看到歐盟對於資料相關的政策,反觀台灣,想問的是,面臨新的資料世代,台灣政府對應的政策是什麼?