G20農業鏈結開放資料會議 Part 5 – 開放地理資料、區塊鏈、溯源

Open GeoData

Open GeoData這個場次有三個演講,分別如下:

  1. Raul Palma de Leon, Publication of Inspire-based agricultural Linked Data
  2. Karel Charvat, Integration of open land use, smart point of interest and open transport maps using RDF
  3. Rob Knapen, Obstacles in standards and spatial thinking for Linked Data in agriculture

前二個演講是同屬於一個歐盟Horizon 2020 巨量資料研究計畫DataBio,有16國48個單位加入,計畫期間為2017年到2020年,總經費規模達到1千6萬歐元,歐盟支援了1千3百萬歐元,是一個針於農業和其它對於生物經濟工業中原物料產品的巨量資料技術優勢的展示,並且佈署一個互操作性的平台在所有計畫成員的資料基礎設施之上,藉由這樣的技術架構這個計畫企圖提供巨量資料管理的解決辦法,包含不同巨量資料的儲存和查詢,以及使用鏈結資料為聯合層來整合來自不同來源之異質性資料。DataBio需要整合先前的歐盟FP7的研究計畫SDI4Apps和FOODIE之資料,如圖41所示。SDI4Apps主要在於建構的是以Open API為主的雲端架構來進行資料整合,並且依此雲端環境建立6個試驗性Apps 與INSPIRE、Copernicus 和 GEOSS 空間資料基礎設施整合。而FOODIE 主要是在建構一個開放和互操作性的雲端基礎平台以整合不同來源的農田生產相關資料,並包含地理空間向度,以及發佈為鏈結資料。

圖41: DataBio計畫由資料整合

在de Leon的演講中主要介紹如何利用FOODIE既有的語彙和標準,並與INSPIRE整合開發出鏈結資料的服務,如下所列。

而Charvat的演講中則進一步介紹如何在DataBio的計畫中整合交通資料(Open Transportation Map)和土地利用資料,其鏈結資料的服務也是從上述的服務中展示,但略有不同,如圖40中的服務是土地利用坵塊,就不是上述的農田分區,但技術上都是一樣的。

圖42: 雲端服務查詢結果的地圖視覺化 http://ng.hslayers.org/examples/olu_spoi/?hs_panel=info&hs_x=1607799.902082933&hs_y=6462976.717926565&hs_z=16&visible_layers=Base%20layer;Land%20use%20parcels

 

第三個演講是Rob Knapen,來自荷蘭Wageningen大學環境研究所,演講內容主要在基於他過去處理農業和地理資料的經驗中,去論述資料整合的問題和鏈結資料的障礙,檢討目前研究計畫事實上對於鏈結資料的使用仍然不夠深入。

圖43: Rob Knapen的演講

供應鏈和追溯(Supply chain and traceability)

這個場次包含了三個演講,前二個是關於區塊技術應用於農業資料上,而第三個即是我的報告,三個演講如下:

  1. Christopher Brewster, Blockchains and Linked Data for agrifood value chains
  2. Liisa Pesonen, Employing the principles of My Data and blockchain to build trust in farm data sharing
  3. Dongpo Deng, Construction and reuse of linked traceable agricultural product records

Brewster博士是來自於荷蘭應用科學研究所(Netherlands Organisation for Applied Scientific Research),他認為鏈結資料沒有用在價值鏈(如農田到消費者)的處理,Schema.org、GoodRelations和產品型態本體的語彙可以被期待用來增加價值鏈的處理,學術上企圖使用知識本體在價值鏈上的處理很少,過去的研究計畫也顯示出鏈結資料方法用在價值鏈上會有一些限制,但並沒有真的被進一步的討論。他認為價值鏈的核心問題在於產品履歷或溯源,但這個產品履歷系統是一個很緩慢的系統。從產品溯源的觀點,他進一步介紹條碼系統GS1,以建構資料鏈結系譜(linked pedigree),而這資料鏈結系譜再導以區塊鏈技術來處理,如圖44即是他演講中所提出來一個整合鏈結資料和區塊鏈的架構。

圖44:鏈結資料系譜和區塊鏈整合

 

Pesonen的演講陳述了很多區塊鏈和MyData的觀念,但缺乏實證,整個演講是一個概念架構研究的介紹。

圖45: MyData、MyFarmData和區塊鏈

 

 

G20農業鏈結開放資料會議 Part 2 – 視覺化、導覽和搜尋

Jerzy Weres, Programming technologies supporting management of Linked Open Data in the domain of cereal grain drying and storage

Jerzy Weres教授是來自波蘭波茲納(Poznan)大學農業及生物技術學院資訊應用系。他認為農業資訊對於農夫或農業工程而言都是重要的基礎,這些資訊有助於做出更好的決策,而要讓決策支援的軟體能與時並進,就必須去使用未來的網路科技,這樣的科技己經可以被用來增加決策支援系統的功能性、可靠性、使用性、可維持性和效能,藉由語意網技術來整合多種不同資訊來源現在已經是未來系統發展的趨勢,語意網技術為基礎的系統的新見解是如何透過整合軟體而讓傳統平台開放和利用智慧型手機的開放近用。

在這個演講中,他分享了他是如何與學生在資訊和農業工程課程上合作開發,並且留下二個資訊系統,一是語意網為基礎的建議系統可以支援分析、設計和管理榖物乾燥、處理和儲存,以及另一個整合系統可支援推估和分析幾何、熱能和不同屬性的農糧及林產。

圖8: 語意網為基礎的建議系統 “Ziarbit” 支援分析和管理榖物處理、乾燥和儲存

榖物處理、乾燥和儲存之語意網為基礎的建議系統中是以UML勾勒出系統的結構和欲解決的問題,再以Visual Studio 2013、Windows Phone SDK 8、Xamarin、 .NET 4.5、 ASP .NET 4.5、 C++/CLI 和 C# 5.0 等程式語言為建構環境,圖8即是主系統 “Ziarbit” 的畫面,其中具有處理RDF和SPARQL的元件,如圖9即是RDF三元組的產生器,系統中使用知識本體來正規化資料,圖10即是描述乾燥機的知識本體圖形化。而他們也發輕量化的手機版本,如圖11所示。

圖9: RDF三元組的產生器
圖10: 乾燥機的知識本體的一部份
圖11: 語意網為基礎的建議系統的輕量化手機版開發

可支援推估和分析幾何、熱能和不同屬性的農糧及林產的整合系統是用來模擬熱能和生質能(如玉米核)的質量轉移過程,可以檢驗物質是非均質、非等向、和不規則的特性,以有限單元格網的3D座標來表現一產品的幾何、熱傳導、溼度傳送係數和可轉換的溼度轉換系數,這個整合系統包含了一個共通的圖形介面,而且整合推估、分析和視覺化農糧和林產之熱及水轉移過程的子系統,這個系統是根據標準的軟體工程方法所建立,並利用Visual Studio 2013和C# 5.0 程式語言為建構環境。這個整合系統名為BioProcessSoft,是一個有圖形化介面和資料庫的系統,並包含三個子系統,3D Mesh Node、BioVis和IPS,圖12是3D Mesh Node子系統的截圖畫面。

圖12: 3D Mesh Node子系統

 

John Fereira, Visualization of Linked Open Data – eye candy for VIVO

John Fereira是康乃爾大學資深程式設計師,是VIVO一開始發展就加入的成員。VIVO在2003 – 2005年間,最早的開始由康乃爾大學針對生命科學領域開發,是以關連式資料庫為主,2006 – 2008 年間,VIVO已經擴展到康乃爾大學的所有領域,並且轉換成以語意網為主,2009 – 2012 國家衛生研究院的支持,VIVO讓國家科學網路計畫可以建立,轉換VIVO成為一個多機構的開放源碼平台,2012 後,VIVO轉換成DuraSpace,成為開放社群發展為主的應用程式,VIVO 因此成為一個開放源碼、開放資料平台、且使用開放知識本體,圖13為VIVO的知識本體。

VIVO也是一個可以讓相關於研究活動的資料可看得到且可及的語意發佈平台,以語意網為基礎的研究者和研究之探索工具,除了可以對「人」進行描述,可以針對其它組織、研究經費,計畫、論文發表、活動、設備和研究資源等項目,進行關係的描述,例如有意義的連結人和活動,而這些關係是雙向的,可以瀏覽從一個點到另一個點的脈絡,以URI連結VIVO以外的人、地方、組織和事件。VIVO是一個跨領域的開放資料平台,開放地分享資料並使用鏈結資料,以連結學者、研究社群、學校,VIVO可以整合多種來源的資料,如系統記錄、職員活動報告、和外部資源(如,文獻資源Scopus、PubMed和NIH RePORTER),它也提供可以提供一個檢視和編輯介面,且可整合和過濾資訊至其它網址。

圖13: VIVO 的知識本體

康乃爾大學的[email protected]網站即是利用VIVO所製作,圖14即是[email protected]網站,而圖15展示了[email protected]架構及其與VIVO的關係,網站可以輕鬆地瀏覽各個學者的著作發表、獲得計畫和金額可在網站一覽無遺,可經由網站瀏覽學者的相關資訊,如發表的著作和獲得的計畫與金額,如圖16 和圖17所示而網站中也提供了四種資訊視覺化方法,文字雲、全球合作的地圖、計畫經費、和研究興趣,如圖18-21。

圖14: 利用VIVO所做的[email protected]網站

 

圖15: [email protected]架構及其與VIVO的關係
圖16: 對於單一學者的查詢及資料展示
圖17: 對於共同作者關連的視覺化

 

圖18: 文字雲

 

圖19: 全球合作的地圖
圖20: 研究經費和計畫的視覺化
圖21: 研究興趣關連視覺化

 

Daniel M. Herzig, Searching Linked Data Graphs with GraphScope

Herzig博士之前是德國卡爾斯魯爾科技研究院(Karlsruhe Institute of Technology, KIT)之應用資訊和正規描述方法研究所(Institute of Applied Informatics and Formal Description Methods, AIFB) 之成員,該研究所亦是歐洲語意網研究的重點研究機構,出產許多知名的語意網研究學者。Herzig博士於2014年共同創辦了SearchHaus,這家公司致力於利用圖管理(graph management)方式於巨量資料的關鍵字查詢,metaphacts則是另一家於2014年成立的公司,致力於知識圖管理的公司,2017年二家公司併整,Herzig博士成為這家公司的營運長,該公司目前約10人左右。

圖22: GraphScope的技術內容
圖23: GrophScope的系統架構

GraphScope 是二家公司整併後的新產品,是一智慧型資料近用引擎,可允許使用者以簡單的方式,如關鍵字,去取用結構化資料,特別是RDF 資料。 透過GraphScope對於關鍵字解析,可提供使用者更精確的查尋結果,如果是下SPARQL queries,使用者需要了解資料綱要(schema)和SPARQL的語法,才可以得到較為準確的結果,但在GraphScope並不需要,所有過於技術的細節使用者是看不到的,也不用了解,GraphScope可以把綱要和語彙內建默記起來以便處理資料,也就是辨認關鍵字,GraphScope也適於用了解資料模型的領域專家,即使不了解語意網和資訊技術,也可以簡單的查詢資料,圖22為GraphScope的技術內容。GraphScope可以部署於三元組資料庫的上層且提供網頁介面,圖23即顯示GraphScope的系統架構。

在農業資料方面,metaphacts幫丹麥農業部門處理資料,在農業資料部份包含農田和作物,在商業資料部份包含土地權屬、公司的住址及並活動的資料,資料的知識本體如圖24所示,利用GraphScope建立系統,如圖25所示。

圖24: 丹麥農業資料知識本體

 

圖25: 查詢誰種菠菜的結果

GraphScope最早應用的領域是在生命科學,圖26所顯示的是利用GraphScope架構的基因庫查詢系統,The Gene Expression Atlas ( http://www.ebi.ac.uk/rdf/services/atlas/ ) 由歐盟生物資訊研究所(The European Bioinformatics Institute, EMBL-EBI) 建構,其畫面為查詢REG1B的基因序列之結果。

圖26: The Gene Expression Atlas (http://www.ebi.ac.uk/rdf/services/atlas/) 

GraphScope在其網站上(https://www.metaphacts.com/graphscope)提供二個展示,一是利用Wikidata,另一個是研究著作的查尋系統ResearchSpace。在Wikidata的展示上登入頁面上,只需要輸入關鍵字,例如,輸入「Taiwan」,搜尋列會列出所有和Taiwan一字有關的實體(entities),如圖27,點選其一,可以找到所有和這個實體有語意關係的實體和概念,其介面提供視覺化介面,如圖28展示出所有和「Taiwan」有語意關係的實體。

圖27: 與「Taiwan」相關的實體
圖28: 與「Taiwan」有語意關係的實體

 

Daniel Martini, Linked Data architecture components – How to attach linked data services to legacy infrastructure?

Daniel Martini是籌辦單位之一德國農業科技與建立協會(KTBL)中資料庫和知識技術組的專家,他們團隊在2004年左右就開始進行AgroXML的建立與發展。在他的演講中一開始先說明了KTBL這個單位的背景,KTBL是一個有註冊的非營利協會,2/3是由德國農業部所資助,有來自於學術、業界的各領域專家約400位成員左右所組成,有70位左右的職員在Darmstadt工作,管理許多工作小組、組織專家工作坊、出席相關委員會、以及維持專家網絡。KTBL的任務是將研究成知識導入農業的實務中,並以專業來支援政策決策,評估新農業技術在經濟和生態在衝擊,以及提供計畫性資料(如,投資、產品處理過程…)到農夫。資訊技術的角色有三: 一為資料獲取,是由開放資料來源中獲得,二為資料處理,是由原始資料轉換為計畫資料,三為資訊提供,透過電子書、網頁和APPS,傳遞農業資訊給客戶。

KTBL並負有一個任務是在於傳遞人和機器都可讀格式的計畫性資料,這其實需要處理(1)人與機器都可讀的類別(classes),如購買價格、供給的消費量…等; (2)標準田野工作流程,如工作時間、在不同制度下機器的共通方式…等; (3)操作供給: 平均價格、內容…等; (4) 設施和建物: 畜舍、牛奶機器和它們的屬性…等,讓以上這些資料能夠被更多的人使用,而且能夠進一步地在軟體應用程式中處理,以便服務農夫。

圖29: 語意網工具評估

在KTBL中有許多資料準備提供分享,而他們想要遵循FAIR原則,而且使用標準規格,如RDF、HTTP、SPARQL,但這些資料早己經存在於既存的系統(基礎設施),他們想的是如何開發出來一個工具箱可以以最少工作來解開這些儲放在既存資料庫中的資料。

因此KTBL的第一步就是開始設計語彙,讓資料能讓「再使用(reuse)」,他們以rdfs:label提供人可謮的名稱,在人名、地址、電話部份,他們使用VCardFOAF語彙,在單位和維度方面,使用QUDT語彙,在地理資訊方面,使用GeoVocabGeoSPARQL,在價格和產品方面,他們使用Good Relations Ontology,有這些語彙他們也建立他們的知識本體。並且開始從既有竹點的資料庫中開始要轉換資料,但在這之前,面對這麼多的工具要怎麼使用成為一個問題,所以他們對於這些工具進行評估,最後決定用D2RQ由資料庫轉RDF資料、用Jena Fuseki來儲存RDF和支援SPARQL 查詢、用ELDA進行序列化和網頁版型, 圖29即是評估過工具和最後決定的評估過程。最後結論也再次強調利用開源工具去建立語意網服務是輕鬆寫意的事情。

圖30: KTBL的語意網服務的系統結構

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

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

[OSM活用術]如何安裝在開放街圖(OpenStreetMap)在Garmin的機台

在台灣買GPS機台,多數只會裝台灣的圖資,而出國時經常面臨有GPS機台沒有圖資使用的窘境; 相反地,在國外買的機台也只裝載當地圖資,往往回台灣後,也會面臨沒圖可用的狀況,就必須再額外購買圖資。其實,開放街圖(OpenStreetMap)提供了一個免費的圖資。

隨著OSM的圖資在世界各地愈來愈完成、豐富,提升OSM圖資實用性。Garmin 目前是GPS熱門廠牌之一,使用者多,在OSM社群中自然有人已經把OSM圖資轉為Garmin機台可讀的IMG檔。以目前還在更新維護的Garmin圖資載點,如圖1所示,是由荷蘭人Lambertus所維護,可以自由地選擇所需圖資之區域,下載該區域的IMG,再置入Garmin的機台,就可以使用。

http://garmin.openstreetmap.nl/
圖1: 可下載Garmin機台可讀的OSM圖資 (garmin.openstreetmal.nl)

步驟很簡單,在圖1中,可以選單方式選擇所需區域,或者勾選手動的方式,選定一個或多個區域,筆者只需要越南河內,因此只選擇河內單一區域,然後填上你的email,按下”Build your map”,如圖2所示,系統會自動產生你所需的IMG檔,並email給你。

Garmin OSM region selection
圖2: 選撢所需圖資之區域

隨著email所提供的連結,來到如圖3的網頁,其中”osm_generic_gmapsupp.zip “,就是可以載入Garmin機台的IMG檔,如果你的電腦上有裝Garmin出產的地圖瀏覽工具,也可以下載在這個頁面中所提供的其它檔案。

Screen Shot 2015-10-08 at 6.20.20 PM
圖3: 經由email提供的連結下載圖資

將IMG修改一下檔名,以免覆蓋掉原本圖資,放上Garmin 機台的資料夾。開機後,縮至使用的地圖區域,如這次範例是在河內,縮到河內,就可以看到OSM的地圖。如圖4。

OSM in Garmin Dakota 20
圖4: OSM圖資在Garmin Dakota 20

用Osmosis將plant.osm資料倒入MySQL資料庫中

Osmosis 是一套處理OSM資料的JAVA應用程式,可以用來輸入輸出OSM資料庫的資料,以及處理dump的OSM資料。之前習慣於用簡單的方式來處理OSM XML資料,擷取出需要的資訊,今天嘗試的使用Osmosis後,才發現Osmosis才是王道。

Osmosis的安裝也很容易,在Mac機器上,只要brew install osmosis即可安裝完成。

OSM本身的database是postgreSQL,若你也使用postgreSQL資料,網路上可以找到不少資料。若資料庫是用MySQL,相對比較少。在github上,有人釋出database schema

連結感測器資料(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資料。

群眾外包的訊息平台 — Ushahidi

Ushahidi 是一套著名的群眾外包 (Crowdsouring) 平台,被運用在許多世界上重大的災難事件中,它的出現是因為2007年非洲肯亞總統大選出現爭議而暴動,為收集肯亞各地暴動資訊,Erik Hersman等人建立了一個以電子郵件和簡訊方式收集暴動事件之資訊,並顯示於Google Map 上,此平台並命名為 Ushahidi ,即為非洲斯瓦希里語 (Swahili) 的「證詞 (testimony)」或「證人 (witness) 」之意,而 Ushahidi 以收集群眾所提供的災難資訊,並繪製於地圖上的方式,也稱為災難地圖 (Crisis Map) 。
Ushahidi平台建立於 Kohana 網頁架構,也就是一個PHP 5 為基礎,提供許多豐富的套件以用來建立網頁, 為 CodeIgniter 架構 (PHP 5 開發環境) 的一個分支。在簡訊收集方面,Ushahidi並內建 Nexmo,用來處理大量手機簡訊(Shot Mobile Message)的API,以及 Clickatell 來提供收集簡訊閘口 (gateway),此外,Ushahidi 也常使用 FrontlineSMS 來收集使用者所發送的簡訊。在地圖顯示方面,Ushahidi使用OpemLayers套件為災難訊息地理視覺化的工具,使用者透過這個套件可以將災害訊息定位,所收集的災難訊息也可以分門別類地顯示於地圖上。圖1為我們所建立的測試平台。

圖1: 我們所建立的Ushahidi測試平台
圖1: 我們所建立的Ushahidi測試平台

SwiftRiver是擴充Ushahidi資料收集的系統,該系統結合自然語言處理和資訊探礦的處理套件,能分析使用者所上傳資料,如Twitter和簡訊,在短時間內,幫使用者分類並提供使用者充份的背景資訊,讓使用者更容易提供資訊,另一方面,資料收集者也因為充份對上傳的災害資訊分析,能有效地歸類整理災害資訊,而使所收集的資訊能加以利用,因此SwiftRiver被定位為具有所生產一個智慧且即時的資料收系統。SwiftRiver具有三個主要功能:1) 組織未結構化資料、 2) 條件式過濾和即時分辨上傳訊息的優先程度、 3) 加入有意義的脈給 (context) ,如位置,圖2為SwiftRiver的使用介面,對於來自於Twitter的事件報告,可以進行內容的過濾與辨識,以利後續分類及訊息分送。

圖2: SwiftRiver的使用介面
圖2: SwiftRiver的使用介面

Ushahidi在世界各地及重大災難事件的使用

(1) 2010年海地地震

在2010年海地地震發生沒多久,哈佛大學人道計畫(Harvard Humanitarian Initiative) 發起人之一, 利用Ushahidi 開啟了一個三個單位聯合的海地人道救援計畫,包含美國塔夫茲大學佛萊契爾法律外交學院(The Fletcher School of Law & Diplomacy at Tufts University)、哥倫比亞聯合國人道事務協調辦公室(UN OCHA/Colombia)和危機資訊製圖者國際網絡(the International Network of Crisis Mappers (CM*Net)),在該計畫開始後的幾個小時,即有許多的人道救援和技術的工作者加入,近40000筆的事件報告被傳送到這個海地地震的Ushahidi,之中有約4000筆的事件被標示於地圖中,圖3這個海地地震的Ushahidi。

圖3: 用來收集與報導2010年海地地震之相關災害訊息的Ushahidi
圖3: 用來收集與報導2010年海地地震之相關災害訊息的Ushahidi

(2) 2011年紐西蘭基督城地震
在2011年2月22日的紐西蘭基督城地震後24小時, 基督城復原地圖(Christchurch Recovery Map) 即利用 Ushahidi 建立起來,該網站標示了重要物資訊息,如食物、水、廁所、燃料、ATM和醫藥用品,其訊息由Twitter以#eqnz這個雜湊標籤、簡訊和電子封件來收集,這個網站由一群網站專業工程師和志工來建立與維護,如圖4所示。

圖4: 基督城復原地圖
圖4: 基督城復原地圖

(3) 2012年東日本大地震

2012年東日本大地震之後,Ushahidi被使用來交換傳遞地震災情與救援相關訊息。圖5為利用Ushahidi建立的日本復原地圖。

圖5: 日本復原地圖
圖5: 日本復原地圖

(4) 2011年美國密蘇里河洪水

MightyMoRiver 計畫是使用 Ushahidi 為 Crowdmap.com 服務的平台來追蹤2011年美國密蘇里河洪水的災害事件。

圖6: 密蘇里河洪水事件災害地圖
圖6: 密蘇里河洪水事件災害地圖

(5) 馬其頓共和國的貪腐事件報告

透明觀察計畫是使用 Ushahidi平台來追蹤馬其頓共和國的貪腐事件, PrijaviKorupcija是一個由馬其頓國際透明組織(Transparency International – Macedonia)和國際關係中心(Center for International Relations)聯合的計畫,旨在使公民可利用手機簡訊、電子郵件和twitter的雜湊標籤#korupcijaMK 來報導馬其頓貪腐事件。

圖7: 馬其頓共和國的貪腐事件地圖
圖7: 馬其頓共和國的貪腐事件地圖