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的語意網服務的系統結構

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: 馬其頓共和國的貪腐事件地圖

群眾外包的交通時況—Google Map traffic layer

日前與友人聊天時談到Google Map的交通時況是收集 Android的智慧型手機上的資訊,當時有點驚訝,我一直以為Google Map是使用交通部的TMC(即時交通資訊廣播),經過一番調查與測試,沒錯! Google Map 上的交通時況就是Crowdsourcing,就是千千萬萬Android 用戶貢獻的,幾點提出來來大家分享:

一、Google Map Traffic 所涉及的範圍比交通部的TMC還廣

TMC在許多都會區道路上都有架設收集的點,但鄉村地區則不足,但Google Map上卻常常有資訊,舉例在草屯鎮,在交通部服務e點通 的地圖上中二高和水沙璉高速公路都有會交通路況,但草屯市區道路看不到路況資訊,在TMC的建置計畫中也沒有草屯鎮道路的資訊,但在Google Map上,有幾條道路顯示出路況。

Screen shot 2013-05-10 at 2.05.54 PM
TMC
Screen shot 2013-05-10 at 2.06.05 PM
Google Map Traffic

 

 

二、Google Map 導航的時間估算變得比較準確

以前使用Google Map 路線規劃,時間的預估和實際狀況有時候因為塞車,使得交通時間變長,曾幾何時,Google Map路線規劃也把交通狀況考慮進去,使得路線規劃的時間變得比交符合現況,或許從Google Map的blog中可以看出一底端倪。從Mashable的這篇報導中,更加讓人確信Google Map Traffic Data是使用Android用戶。

Data is gathered through third-party services and through information from Android users who have opted in to the My Location feature on Google Maps. Google would be able to tell, for instance, if there were several Android owners moving slowly on the freeway and determine that there was traffic slowing them down. The more people opting into the service in the area, the better the traffic information available will be.

 

三、Google Map Traffic會出現一些與現實路況不符的情形

根據觀察,Google Map交通時況在中研院門口附近於中午時候,常有塞車的情況,但事實是如此嗎? 想想中午的時候有許多人用“走”出去吃飯,如果Google Map交通時況是集合Android GPS訊號而轉換得到的資訊,這些被標示塞車的路段,可以合理的被懷疑是因為集合多數人”走”速度,而讓Google Map交通時況的判斷為塞車?

Screen shot 2013-05-10 at 1.41.21 PM
中午時,中研院附近的Google Map Traffic

 

Enhanced by Zemanta