如何利用開放資料解決農業和糧食的問題

以下文字是取自於 ODI(Open Data Institute)在2015年發表的報告「How can we improve agriculture, food and nutrition with open data? 」,主要想分享報告中所整理的14個案例。

因為開放資料是任何人都可以近用、利用和分享的資料,這所形塑的解決問題之道,相對於不開放的資料是昂貴的、耗時的且不可能的。透過加快創新速度,開放資料促進了政府、商業、NGOs和個人的協同合作,得以有新的發現,以幫助永續地提供糧食於不斷增長的人口。這份報告區分出三個關鍵方向,其中開放資料在農業和糧食的挑戰中扮演解決問題的重要角色,這三個方向為:

  • 讓更有效、有影響的決策可以產生
  • 培植讓所有人都可以受惠的創新
  • 藉由透明化,趨使組織和部門的改變

讓更有效、有影響的決策可以產生

1. GroenMonitor: 以植被分佈圖防止害蟲爆發並保護農作物

田間生產量常因農作物受到害蟲侵襲而損害,在廣大的農田中,很難用人工方式偵測到老鼠或其它害蟲的入侵,GroenMonitor (GreenMonitor)是一個利用荷蘭的衛星影像所製成的植被圖來監控害蟲入侵的工具,其衛星影像是來自於歐洲太空總署 (European Space Agency, ESA)所釋出的開放資料,利用開放的衛星影像所製成植被圖,使得害蟲爆發的容易被辨識出來,在2014年,GroenMonitor 已經被用來辨識出12,000公頃受到鼠害的農地,這個工具現在還整合其它不同應用程式,包含植物物候學、作物辨識和產出、農業活動的辦識(如除草、犛田、和收割)、自然和水管理。

2. AWhere: 以氣象應用程式和簡訊預測幫助農夫

對於農夫而言,他們很難去取得影響他們耕作活動的基本資訊,如溫度高低、溼度和降雨,特別是在低度網路使用的地區,但很多資料提供者現在可以提供所需的氣象資料給個別農夫。AWhere 就是其中一個,透過他們全球資料庫和Weather Terrain,AWhere 結合從全球尺度到田間尺度的氣象觀測、預測模式、和歷史資料,幫助農夫做好的預測和規劃農業活動。

許多農夫,特別是發展中國家的,使用行動電話(而不是電腦)作為他們主要通訊的工具,因為這樣,迦納在地社群與AWhere一起合作,去發展一個APP在 Weather Terrain的Open API之上,以讓他們豐富的資料得以透過行動電話來使用,而這個使用方式是,氣象資料被轉換成簡訊服務,使用基本關鍵字(如,部份晴天的、部份多雲的、有風的)和照片,農夫可以低成本的方式使用氣象資料,讓他們可以決定關於耕作的事務。

3. Plantwise: 以最佳實務知識庫來增加農作用產量

約40%的全球作物產量損失是因為植物病蟲害,Plantwise幫助開發中國家的小農處理植物健康問題,它著重於增加糧食安全和改善鄉村生活以減少作物因病蟲害的損失,從 CABI(Centre for Agriculture and Biosciences International)的資料庫、研究論文和政府等資料,整合出全球和地方的開放近用的資料庫,使資料可以在線上平台取得和查詢,從全球各地的植物診所的疾病診斷報告,可以用來補充知識庫,並通知在處理蟲害的在地夥伴。

在二年發展下,Plantwise知識庫己經成為一個必要工具,以支持在33個國家的植物診所診斷,超過來自於198個國家的六十萬農夫造訪了這個知識庫,包含使用了超過九千筆的報表來取用關鍵的與作物蟲害相關的農業資料和最佳實作,去幫忙管理和預防作物在病蟲害的損失。Plantwise在2014年也獲頒ODI的對於社會影響的開放資料獎

4. CIAT Colombia: 以智慧氣候工具在旱災中省下3.6萬

這是一個最近利用公私資料的協作的案例,其成果幫助農夫得到預警,以避免旱災在哥倫比亞所造成的損失,在2007-2013年間,國際稻農組織(National Federation of Rice Growers; Fedearroz)、熱帶農業國際研究中心(Centro Internacional de Agricultura Tropical; CIAT)、和哥倫比亞農業部一同合作來處理旱災在稻米產量減少的議題,稻米是哥倫比亞重要的糧食之一  (詳見 Stuart, E, E. Samman, W. Avis and T. Berliner, 2015, The data revolution – Finding the missing millions, 37p)。

公私資料的使用,私部門資料取得是透過特別條款,CIAT 得以分析來自於每年稻米調查、採收記錄、田間試驗、和天氣資料的大資料集,且辨識出在稻米產量減少背後的複雜和區域特定之議題,根據分析,再去發展智慧氣候農業決策工具給哥倫比亞稻米種植者,而工具其實是開放給任何人的

無論是在農業部門,還是對於哥倫比亞的經濟的影響都是重大的,農業活動進行是根據 資料分析結果,幫助了農夫避免旱災造成的重大損失,省下估計360萬美元可能的經濟損失。這個智慧氣候的工具在2014年羸到聯合國巨量資料氣候挑戰頭銜

5. 加州水資源局: 以資料視覺化管理加州旱災

加州正經歷在過去記錄上最嚴重的旱災之一,缺水造成農業部門嚴重的威脅,農業的水利用是大約是整個州的80%左右,在2014年的農業部門的經濟直接損失預估有15億美元,在食物生產減少上有1萬7千工作喪失 (2014年加州旱災的經濟損失報告),為了確保安全和永續的水資源,加州水資源局宣布水供給計畫,這計畫減少了水分配到農地並減少了25%的用水。

開放資料被用來告訴州政府如何重新分配嚴峻的水資源,其方式是美國地質調查局(USGS)將乾早的情形視覺化,視覺化所使用的資料是由USDA研究機構群所收集,且開放近用的資料,這些資料涉及了農業永續、氣候變遷和自然資源保育在集水區尺度或景觀尺度之長期的自然、化學和生物資料,這使得研究人員和決策者得以監看水管理的狀況和計畫,根基於資料的模式,可以經常的更新、推估真實水量的水準、用水量和其它因子,並允許適時地預測和決策多少水量用於農業上。

美國農業部 (The US Department of Agriculture, USDA) 也研究了相關加州乾旱資料的開放,Catherine Woteki 博士希望這將是刺激公私部門在開放資料的使用,以幫助農夫在用水和作物選擇的決策支援。

培植讓所有人都可以受惠的創新

6. Climate Corporation: 以天氣模擬和智慧保險,省下作用和金錢

在過去,天氣預測模式中讓農夫很掙札,這些模式沒有把在地狀況納入考量,而導致沒效率的風險計算。Climate Corporation是一個開放資料商業公司,提供更為準確的保險和商業諮詢服務,以幫助農夫管理和調適氣候變遷。

透過分析大量來自於開放和其它來源的資料,對於特定作物產量進行模擬天氣事件和評估風險,因此他們得以提供專業的諮詢和準確的保險。

這公司使用開放資料是來自於美國國家海洋暨大氣總署(NOAA)美國國家氣象局的159個都卜勒雷達站、以及美國地質調查署(USGS)的地形圖和土壤分佈圖,Open Data Now的介紹

農夫使用詳細的天氣預測資以強化他們農耕行為和活動,如澆水、施肥、和播種,舉例來說,農夫可以使用這家公司所提供的溼度和降雨分佈圖,知道他們農田的特定區域是否過於溼潤而不能耕作。在一個工業水準上,開放資料加持的服務對這家公司的影響可以是很大的,在2013年,Climate Corporation的客戶使用他們產品耕作了超過一千萬英畝的農地

7. AgTrials: 以育種試驗的開放資料來改善作物品種

培育品種試驗是一個改善農作物品種的重要方法,在全球各地都有各式各樣的試驗在進行,這些試驗各著重於不同的主題,如耐旱、熱逆境和土壤管理,然而,這些資料幾乎都不能被其它研究人員所使用,而只是放在實驗室的硬碟中,甚至因為資料管理不好而造成資料逸失,形成不完整的資料集。

藉由農藝和植物育種試驗資料的整合和開放資料,由CGIAR在氣候變遷,農業和糧食安全研究計畫所負責的 Global Agricultural Trial Repository (AgTrials)  提供豐富的知識庫讓協同合作的計畫得以進行,去除掉非必要且有成本的重複工作。

科學家使用250個開放的AgTrials 資料集,以建立西非區域的農作物模式,這個模式被用在一個氣候變遷對於在地影響的計畫,並用來定義氣候變遷調適的育種計畫

8. FAO AGRIS portal: 把農業研究帶向大眾

AGRIS 是一個研究機構和資料節點的國際網絡,這個網絡讓農業研究資訊在全球可以取得,他們從在65個國家超過150個資料提供者中,收集且分享多樣的食物及農業出版品之書目資訊。

AGRIS 成為書目資料成為一個匯整平台,藉由超8百萬筆記錄的開放資料儲存庫,讓相關內容在線上有位址且可以組織這些內容,應用程式將在這個開放資料儲存中的記錄與連結網址與其它有品質的資料來源,例如世界銀行(World Bank)、自然期刊(Nature)、和中國種質資料庫(Chinese Germplasm Database)

AGRIS 平台已經有來自於204個國家超過750萬的人造訪,這些訪客從大學生到研究生都有,AGRIS 成為科學和技術資訊的最重要節點。

9.  CIARD RING: 讓農業食品(agri-food)資料更容易查找

儘管已經有很多相關於開放資料的資訊 (像資料集、平台、標準),相關資訊的檢索仍然是需要關注的重要議題,在這個脈胳下,CIARD R.I.N.G. 的資訊節點和閘道扮演了全球性農業研究發展(ARD)之註冊的網路資訊服務。

這個註冊服務允許資料提供者登記和分類他們的服務,在確保所有資料集都完成對於那種使用標準的詮釋資料(如語彙、範圍和標準)下,註冊的服務促進且利用了標準,而標準的使用促進資料的再使用(reuse)和被查尋,且允許更好自動化,現在約有1/3的農業食品資料集,即有超過1000個資料服務是具有特徵。

藉由透明化趨使組織和部門改變

10. Syngenta: 以開放且協作的平台來追蹤水、農藥、燃料的使用

在2013年,Syngenta宣布了他們的「好成長計畫 (Good Growth Plan)」,其中有6項承諾以改善農作物產量、保護土壤和生物多樣性,以及訓練小農和確保工作標準,並設定於2020年完成目標。這個行動著重於透過監測活動,如肥料和農藥利用及水和燃料的使用,讓農夫以永續的方法來增加農作物產量。

資料管理系統被建立於用來追蹤這些使用農地和公開農業資料的輸入輸出,由獨立的公司收集、驗証和分析

因應6項承諾的2014年的基準資料以機器可讀的格式(CSV)、CC-BY-NC-ND的條款釋出,透過這些行動,Syngenta和ODI合作,去建立一個開放且協同合作平台,以找出方法解決餵飽日漸增加人口的需求下減少資源使用,以及為生態多樣性而保護棲地。

11.FUNDAR: 在墨西哥找出不當使用的農場補助

在墨西哥,PROCAMPO 是一個最大的聯邦農場補助計畫,支援最貧窮農夫,自從2007年,他們開始關注真正極需要幫助的農夫,卻沒有拿到補助。

為了更了解這個情況,一個墨西哥的NGO組織,FUNDAR 研究分析中心徵求墨西哥農業部處理補助發放的相關資料,這個中心一開始拿到的資料是不完整且機器不可讀格式,在處理分析後,發現57%的受益者是分佈在最富有的10%之補助者,初步確認了他們所 害怕的事

這個重要的結果是來自於FUNDAR和其它NGO建立資料庫 (Subsidios al Campo en México)的貢獻,這個資料庫也不斷地發佈農場補助的資訊,以確保更透明化,以致於一系列的官員下台,且墨西哥政府也增加補助合格的限制。

12. 美國國家營養資料庫: 賦權消費者去聰明的選擇食物

消費者都會想知道他們買的食物之品質和內容物的資訊,雖然基本資訊已經標示在食品包裝上,但更詳細的食物營養資訊可以讓消費者依照個人需要做出更好的選擇,例如,遵從營養師指示。

美國農業部國家營養標準資料庫的(USDA National Nutrient Database for Standard Reference, SR25)是一個食物成份資料的主要來源,提供給公私部門,SR25包含約150食品公司中超過8,500食品品項的營養資料,例如維他命、礦物質、胺基酸、和脂肪酸,這些資料不限於商業應用(如,智慧型手機APP),這資料庫提供政府做了一個基本的服務 ChooseMyPlate.gov,由前美國第一夫人蜜雪兒歐巴馬和農業部祕書長湯姆·維爾薩克( Tom Vilsack)開始倡議,提供實務的資訊給個人、健康專業人員、營養教育者、和食品工業,以資源和工具幫助消費者做出飲食評估、擁有營養教育和其它友善的營養資訊,以建立更健康飲食

13. 歐盟食物警示: 幫助消費者了解他們吃的食物之風險

食物安全是另一個對消費者影響甚大的重要議題, 歐洲 RASFF (Rapid Alert System for Food and Feed) 平台 提供一個使用的資料庫,這資料庫收集的公開可得資訊是最近傳出的食品安全警示和通知,

消費者可近用資料於食品安全議題,例如出現在食品中過敏原,病原體,毒素或其他有害物質,以及分享預防資訊因為2011年福島核災,RASFF被用於監測來自於太平洋區域魚類和其它海洋產品中可能危害消費者的輻射殘留

How does RASFF work

14. LIVES: 標示餐廳檢查分數改善食品安全

開放資料也可以被用來幫助消費者去選擇那裡用餐,同時也促進改善食品安全的動機,LIVES (Local Inspector Value-Entry Specification) 是一個餐廳評分標準,目的在於標準化在不同管轄區的餐廳檢查分數,讓消費者了解不同城市和自家城鎮對食品安全的規格的不同。LIVES是在舊金山、Socrata, Code for America, 和Yelp在2013年所開始的計畫,它提供了餐廳檢查開放資料發佈的標準。因為市民得以更好的使用檢查結果,LIVES 事實上使食物容易清楚了解且可以選擇通過檢查的餐廳,當洛杉磯市開始要求餐廳要放衛生檢查等級在入口處,研究顯示減少了13%的因食源性疾病的住院治療

鏈結農產品產銷履歷資料(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 所示。

圖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」的那裡吃
圖34: Chrome瀏覽器擴增模組「LinkedFood」的推不推
圖35: Chrome瀏覽器擴增模組「LinkedFood」的產銷履歷瀏覽

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

參考文獻

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