鏈結開放資料與其情境感知應用之研究
64
0
0
全文
(2) 摘 要 鏈結開放資料與其情境感知應用之研究 馬聖儒 政府公開資料(Open Gov Data)在各國逐漸盛行，2009 年美國政府公開資料平台(data.gov)以及英 國政府公開資料平台(data.gov.uk)上線以來，各國家都開始發展自己的政府公開資料平台。台灣也不 落人後，從台北市政府開始、陸續有台北市公開資料平台、政府公開平台...等等資料，供人民或開發 者使用。但是綜觀目前台灣各中央、地方政府，雖然陸陸續續開放了很多資料，但是卻遇到了很多問 題：格式雜亂、格式不易運用、資料授權複雜...等等，使得人民、開發者難以針對這些資料進行應用、 開發服務。 本研究利用鏈結公開資料(Linked Open Data)的概念，使用語意網路技術，加強資料的可讀性、開 發性，並且提供語意網路存取語言的介面，讓資料更容易被使用，以便從資料中挖掘更多的價值。另 一方面，為了讓應用更貼近使用者，本研究採用了情境感知(Context Awareness)方式開發應用，讓應 用能更貼近使用者的生活。為了驗證上述概念，本研究實作台北市公開資料中的三個資料集整合至停 車場推薦系統，從應用的起點：『開放資料』，一路到『使用者端』，實作一個有效、可塑型高、且 更親切的系統模型。. 關鍵字：政府開放資料、鏈結開放資料、情境感知. i.
(3) ABSTRACT Study on Linked Open Data and Implantation of Context-Awareness Sheng-Ju Ma Open Government Data gradually prevailed across the world. Since data.gov and data.gov.uk launched one by one in 2009, lots of countries developed their own Open Government Data platform, and so does Taiwan. The Platform of data.taipei.gov.tw is the first Open Gov Data platform in Taiwan. Now there are many Open Gov Data platforms, such as data.gov.tw and data.taichung.gov.tw, for any usage of people or developer. These platforms have numerous data, however, with messy format and poor data retrievability, which is hard for developer to implement services. Therefore, this study follow the standard of Linked Open Data, using Semantic Web Technique to normalize data, and providing Semantic Web Query Interface, SPARQL, to access data. By doing so, we can use these open data much easier, and discover more information from data, to create more value from these. Besides, in order to create better application experience for users, this study includes Context Awareness to make the application fit the user’s life. To implement these concepts, this study implement a Taipei Parking Garage Recommendation System, which combined three of datasets on Taipei open gov data platform, to create an efficient, convenient and flexible system model.. Key Word: Open Government Data, Linked Open Data, Context Awareness.. ii.
(4) 誌謝 兩年研究所的時間，非常感謝葉耀明老師一直以來的帶領，除了讓我參與許多研究計畫，也見識 到不同產業、領域上的專業，在這兩年，除了分內的知識學習，也見習到不一樣的工作模式與計畫參 與，認識了社會上不同單位、不同領域的人，讓我在碩士兩年，提前對社會脈動有粗淺的認識。 此外這段期間，也很謝謝學長不吝幫忙、分享各種研究所或實驗室的經驗，讓不善與人溝通的我 也能夠順利融入這個實驗室。其中特別要感謝書銘學長，不只是在碩一，即使在碩二期間也幫助我很 多，使我能在工作與課業上順利取得平衡。也要謝謝馨民、名甫、念學的幫忙，特別是眾多研究計畫 與實驗室的雜事上給予協助，讓我能夠順利完成我的研究。 另外要謝謝新芽網路有限公司的各位同事，在忙碌的研究生活中，提供我調劑身心的管道，也謝 謝新芽老闆能容忍我這個不定時上下班的實習生。最後要謝謝家人的支持與鼓勵，讓我能無慮的完成 碩士學業。謝謝一路幫助我的各位朋友。. iii.
(5) 目錄 附圖目錄 附表目錄. vi vii. 第一章 緒論...................................................................................................................................................... 1 1.1 研究背景............................................................................................................................................. 1 1.2 研究動機與目的................................................................................................................................. 4 第二章 文獻探討.............................................................................................................................................. 6 2.1 情境感知(Context Awareness) ........................................................................................................... 6 2.2 2.3 2.4 2.5. 開放資料(Open Data) ......................................................................................................................... 8 政府開放資料(Open Government Data) ............................................................................................ 8 鏈結公開資料(Linked Open Data) .................................................................................................. 10 資源描述架構(RDF) ........................................................................................................................ 11. 2.6 SPARQL............................................................................................................................................. 13 2.7 Google API......................................................................................................................................... 13 第三章 系統規劃............................................................................................................................................ 15 3.1 鏈結資料圖(Linked Data Diagram) ................................................................................................. 16 3.2 情境感知(Context Awareness) ......................................................................................................... 22 3.3 空位資訊預測................................................................................................................................... 23 3.4 使用案例圖(Use Case Diagram) ...................................................................................................... 26 3.5 活動圖(Activity Diagram) ................................................................................................................ 27 3.5.1 瀏覽合適停車場.................................................................................................................... 27 3.5.2 使用者瀏覽情境設定............................................................................................................ 29 3.5.3 使用者新增情境規則............................................................................................................ 30 3.5.4 使用者刪除情境規則............................................................................................................ 31 3.5.5 系統主動推薦 – 依據情境規則.......................................................................................... 32 3.5.6 系統主動推薦 – 依據 Calendar Event ................................................................................ 34 3.5.7 分析空位................................................................................................................................ 36 第四章 系統開發與實作................................................................................................................................ 37 4.1 系統架構........................................................................................................................................... 37 4.2 類別圖(Class Diagram) .................................................................................................................... 40 4.3 循序圖(Sequence Diagram).............................................................................................................. 41 4.3.1 瀏覽停車場............................................................................................................................ 42 4.3.2 查詢情境規則........................................................................................................................ 43 4.3.3 新增情境規則........................................................................................................................ 44 4.3.4 刪除情境規則........................................................................................................................ 45 4.3.5 主動搜尋 – 情境規則搜尋與推播...................................................................................... 46 4.3.6 主動搜尋 – Calendar Event 搜尋與推播 ............................................................................. 48 4.4 實作畫面........................................................................................................................................... 49 iv.
(6) 4.4.1 瀏覽停車場與導航................................................................................................................ 49 4.4.2 瀏覽/新增情境規則 .............................................................................................................. 51 第五章 結論與未來發展................................................................................................................................ 53 5.1 結論................................................................................................................................................... 53 5.2 未來發展........................................................................................................................................... 54 第六章 參考文獻............................................................................................................................................ 55. v.
(7) 附圖目錄 圖片 圖片 圖片 圖片 圖片 圖片 圖片 圖片 圖片 圖片. 1-1 台北市政府資料開放平台 .............................................................................................................. 2 1-2 鏈結資料圖(Lined Data Diagram) [7] ............................................................................................. 3 1-3 公開資料類別個數 .......................................................................................................................... 4 2-1 情境感知服務流程 .......................................................................................................................... 6 2-2 RDF 範例一 .................................................................................................................................... 12 2-3 RDF 範例二 .................................................................................................................................... 12 2-4 RDF 關係描述圖 ............................................................................................................................ 13 3-2-1 系統規劃圖 ................................................................................................................................. 15 3-2 台北市政府公開鏈結資料圖 ........................................................................................................ 17 3-3 台北市公開鏈結資料圖 ................................................................................................................ 18. 圖片 圖片 圖片 圖片 圖片 圖片 圖片 圖片 圖片 圖片. 3-4 情境規則系統模式圖 .................................................................................................................... 22 3-5 空位個數趨勢圖一 ........................................................................................................................ 24 3-6 空位個數趨勢圖二 ........................................................................................................................ 25 3-7 使用案例圖 .................................................................................................................................... 26 3-8 活動圖 – 瀏覽合適停車場 .......................................................................................................... 27 3-9 活動圖 - 使用者瀏覽情境設定 ................................................................................................... 29 3-10 活動圖 – 使用者新增情境規則 ................................................................................................ 30 3-11 活動圖 – 使用者刪除情境規則 ................................................................................................ 31 3-12 活動圖 – 系統主動推薦(依據情境規則).................................................................................. 32 3-13 活動圖 – 系統主動推薦(依據 Calendar Event) ........................................................................ 34. 圖片 圖片 圖片 圖片 圖片 圖片 圖片 圖片 圖片 圖片. 3-14 活動圖 – 分析空位 .................................................................................................................... 36 4-4-1 系統架構 ..................................................................................................................................... 37 4-2 類別圖 ............................................................................................................................................ 40 4-3 循序圖 – 瀏覽停車場 .................................................................................................................. 42 4-4 循序圖 – 查詢情境規則 .............................................................................................................. 43 4-5 循序圖 – 新增情境規則 .............................................................................................................. 44 4-6 循序圖 – 刪除情境規則 .............................................................................................................. 45 4-7 循序圖 – 主動搜尋(情境規則搜尋與推播)................................................................................ 47 4-8 循序圖 – 主動搜尋(Calendar Event 搜尋與推播) ...................................................................... 48 4-9 瀏覽停車場/選擇時間與區域 ....................................................................................................... 49. 圖片 4-10 觀看停車場訊息，並且啟動導航 .............................................................................................. 50 圖片 4-11 瀏覽情境規則，新增情境規則 .................................................................................................. 51 圖片 4-12 系統主動推薦，瀏覽推薦 .......................................................................................................... 52. vi.
(8) 附表目錄 表格 表格 表格 表格 表格 表格 表格 表格 表格 表格. 3-1 Data Schema - information .............................................................................................................. 19 3-2 Data Schema - location .................................................................................................................... 19 3-3 Data Schema - time.......................................................................................................................... 19 3-4 Data Schema - parking .................................................................................................................... 19 3-5 Data Schema - contact ..................................................................................................................... 20 3-6 Data Schema - police ....................................................................................................................... 20 3-7 Data Schema - context ..................................................................................................................... 20 3-8 Data Schema – 停車場資訊 ........................................................................................................... 20 3-9 Data Schema – 停車場即時空位資訊 ........................................................................................... 20 3-10 Data Schema – 警察局資訊 ......................................................................................................... 21. 表格 表格 表格 表格. 3-11 Data Schema – 消防局資訊 ......................................................................................................... 21 3-12 Data Schema – 情境資訊 ............................................................................................................. 21 3-13 空位資訊預測試算表一 .............................................................................................................. 24 3-14 空位資訊預測試算表二 .............................................................................................................. 25. vii.
(9) 第 1 章 緒論 1.1 研究背景 智慧型手機已經越來越普及，根據統計 [1]，在2013年，台灣的智慧型手機的普及率以達51%， 台 灣民眾出門必定會帶智慧型手機出門的比率也已經達到高達81%，幾乎每兩個人之中，就有一位是隨 身攜帶智慧型手機。智慧型手機已經越來越貼近人類的生活，現在人的生活已經離不開智慧型手機， 舉凡娛樂、休閒、通訊、搜尋...幾乎所有的數位活動都經由智慧型手機，甚至不少人反應：『寧願沒 有電視，但一定需要有智慧型手機』。另一方面，智慧型手機的功能已經越來越強大，除了原本的通 訊功能，還包括上網、GPS定位、三軸加速度...等等，各種晶片與感應器的導入，智慧型手機能提供 的服務也越來越多元。綜合以上智慧型手機同時具有：1. 貼近現代人的生活 2. 強大且便利的服務 3. 各種感應晶片於一身，這三大特點，使得智慧型手機也成為情境感知(Context-Awareness)系統視為重 要的發展平台。 近年來各國政府逐漸在推廣政府開放資料(Open Gov Data)的政策，希望藉由將政府資訊的公開化、 讓市民大眾可以自由的取用，甚至加以運用，讓這些資料能產生更多的價值。台灣目前有不少政府單 位已經有提供類似的平台，第一個上線的是台北市政府開放平台(Data.Taipei)，於2011九月上線 [2]。 政府開放平台(data.gov.tw)也於2013年4/29上線 [3]，時時至今日，新北市、台中市、高雄市、宜蘭縣 等政府單位也都有開放資料平台 [4]。政府資料開放化已經是趨勢，許多基於公開資料的服務也如雨 後春筍般推出。. 1.
(10) 圖片 1-1 台北市政府資料開放平台. 當網路越來越發達，所蘊含的Content也越來越多，於是我們也漸漸踏進來了Web3.0的時代 [5]。 Web3.0目前引起了很多討論，包含著非常多面向，例如要求網路基礎設施要能有效的提升、虛實整 合、以及物連網…等，其中，還有一個面相是對於Content的討論，也就是『資料』。目前散佈在網 路上的資料，大多以超文本(Hypertext)的方式呈現，相當難以整合、分析，很能看出資料與資料的關 係，也不具有機器可讀(Machine-readable)，此外資料只能以網頁超連結的方式相互連結，而不是以資 料本身做連結。於是乎，越來越多人強調『資料』本身的重要性，希望資料能以一個通用、電腦可讀 的格式儲存，並且彼此可以相互連結，Linked Data就是其產物。Lined Data以W3C制定協定為基礎， 提供一種讓大家描述自己資料的方式，並且藉由公佈自己的資料、與其他資料鏈結，讓資料群集能越 來越大，所蘊含的能量也會越來越大。. 2.
(11) 2007年，由University of Leipzig、Freie Universität Berlin以及OpenLink Software共同發表了一個資 料集：『DBpedia』 [6]，是一個基於Wikipedia的的資都有一個Info Block，是一個具由結構的資料組 成，DBpedia就是擷取Info Block，去描述每個Wikipedia條目，建立起Linked Data。DBpedia是目前最 為人所知的Linked Data，也啟發越來越多人響應，與DBpedia相互連結的Linked Data也逐漸擴大，目 前已經有超過50個資料集與DBpedia相互鏈結。. 圖片 1-2 鏈結資料圖(Lined Data Diagram) [34]. 3.
(12) 1.2 研究動機與目的 Open Gov Data的盛行，帶動一波新的網頁、手機應用程式的興起。根據台北市政府資料開放平 台所公開的資訊，目前已經有多達323種資料來源，其中大部份是與市民相關的公共資訊以及交通相 關資訊(可參考下圖)。台北市政府為了響應政府公開資料的使用，於2011至2012年間舉辦3場資訊應 用創意競賽，吸引學生及一般開發者利用台北市政府資料開放平台的資料開發各種加值應用及服務， 目前已經共累積10組得獎作品並上架。台北市政府本身也推出自行開發的行動app，分別在Google Play 以及App Store上架，目前兩邊平台分別已經有28及23個基於開放資料的官方行動app，其他業餘開發 者的所開發的app更是不計其數。. 生命禮儀, 3 環境保護, 7. 其他, 19 公共資訊. 休閒旅遊, 29. 交通與通訊 公共資訊, 138. 交通運輸 休閒旅遊. 交通運輸, 55. 環境保護 生命禮儀 其他 交通與通訊, 72. 圖片 1-3 公開資料類別個數. 雖然目前已經有很多基於公開資料的行動加值服務及應用，絕大部分只是將政府提供的資料整理， 提供一個方便搜尋、瀏覽的介面供一般大眾使用，並沒有對開放的資料進行更多的分析使用，著實可 惜。目前社會處於一個「人手一智慧手機的」時代，智慧手機能做到的事情將遠遠多過『查詢資料』， 4.
(13) 藉由智慧型手機，我們可以掌握到使用者身處的時間、地點、甚至是狀態，配合其他服務，我們還可 以知道使用者未來的行程、對事物的喜好，當我們掌握這些訊息，配合Open Gov Data，我們可以提 供更貼近使用者生活的資料。 另外本研究也針對『資料本身』進行探討。台北市政府公開資料平台所提供的資料，不只格式眾 多，而且可讀性相當差，相當難做多項資料的整合分析或應用，所以本研究希望運用Lined Data的規 範，利用W3C所提供的協定描述台北市政府公開資料，一方面解決格式混亂的問題，一方面讓資料 與資料本身可以加以鍊結，強化資料的力量，進而從資料群集中，得到有用的資訊。. 5.
(14) 第 2 章 文獻探討 2.1 情境感知(Context Awareness) 情境感知(Context-Awareness)是指利用行動裝置偵測、統整使用者目前的位置資訊及狀態資訊， 進而可以自動地提供符合使用者目前需求的資訊、服務。在此前提之下，系統會給予符合使用者目前 所需、符合使用者目前情境的服務或資訊，進而減少多餘、不必要的資訊，服務也能夠貼近使用者。 情境感知最早是由Schilit與Theimer [7] [8]在1994年所提出的概念，主要是利用無線傳輸的技術， 將使用者所需要的、可利用的資訊，依據使用者所在的位置及情境，傳送至使用者。 「情境(Context)」 是用來描述使用者周遭任何實體與非實體的狀態資訊。實體可以為人、交通工具、其他物件；非實體 包含時間、天氣、季節、經緯度…等。總體來說，任何能與使用者產生互動的東西，皆可列入參考依 據，其中也包含使用者本身以及應用本身；互動過程中產生的資訊內容都可以作為「情境資訊」。 情境感知服務流程 [9]如下：. 情境資訊. 感測器. 資訊處理. 服務模式 圖片 2-1 情境感知服務流程. 6.
(15) . 情境資訊：包括使用者資訊，例如年齡、性別、喜好…等等，以及其他環境資訊，例如時間、 位置…等等. . 感測器：利用行動裝置軟硬體感測所獲得的資訊，例如時鐘、GPS、陀螺儀；臉部辨識、使 用者資訊偵測、使用歷程、喜好紀錄…. . 資訊處理：可分為集中式或分散式處理。集中式處理需要將以上所獲得的資訊，利用無線通 訊系統傳回伺服器，經由伺服器加以整合、統整，將符合使用者情境的結果回傳給使用者； 分散式是在使用者的行動設備端進行資訊處理，直接產出結果。. . 服務模式：依照David Kotz的定義，可以將情境模式分為主動服務模式(Active Context)及被 動服務模式(Passive Context)。主動服務模式是指系統會在接收到處理過的情境資訊之後，主 動地改變系統行為、或執行其他程式，例如發出鈴聲；被動服務模式則是當系統接受到情境 資訊，會改變其他系統資訊內容或呈現方式，例如使用者位置在台北，則呈現台北的氣溫。. 依資訊內容，可以將資訊分類成五大區塊： . 空間資訊：位置、速度、海拔等。. . 時間資訊：年份、季節、月份、白天夜晚等。. . 社會資訊：個人社經身分、相關聯絡人等。. . 環境資訊：氣溫、天氣、交通等。. . 設備資訊：無線上網設備、停車位、公車狀態等。. 7.
(16) 2.2 開放資料(Open Data) 指經過篩選的資料，不受任何專利權、著作權、或其他主管機關與管理機制限制，任何單位與個 人皆可自由取用，甚至可以加以出版或是進行加值服務。拜網際網路崛起、Web 2.0 興起，各種「開 放運動」逐漸盛行，例如開放原始碼、技術開放等等，各領域都有類似的因開放而引起新興運動：網 路上是出現各種開放原始碼平台；Linux 的開放技術越來越盛行；硬體界也開始吹起 3D 列印...等等， 都是開放運動的成果。「內容開放」也是被大家所關注的議題，主張各專業領域能將所掌握的資料內 容公開，以增加技術的交流，Science Commons 前執行長 John Wilbanks 提到：「許多科學家都曾經 指出，在這歷史的一刻，正當我們擁有技術能力將科學資料以全球性的層次來發佈和送出，加強彼此 之間的合作關係和加快加深新科技的發明時，很諷刺的看到我們忙著將資料封閉起來，並嚴禁使用更 先進的技術在這些知識上 [4]」。另一方面，也有人認為某些單位所掌握的各個資訊，是源自於一般 大眾所提供，但一般使用者卻無法使用這些資訊，故想藉由內容開放，將這些資料的使用權還給大眾。 內容開放運動的興起，使得學界、政府等都有 Open Data 運動。 依據 W3C eGov Interest Group [10]的定義，Open Data 必須要符合以下標準： i.. 格式未加工(Raw Format)：資料本身不能經過多餘的加工。. ii.. 機器可讀(Machine-readable)：資料格式可以電腦或程式讀取並加以處理。. 2.3 政府開放資料(Open Government Data) 顧名思義，政府公開資料即是由政府平台提供各種施政時所匯集的公開資料給全民使用。政府施 政透明是世界各國政府推動的趨勢，經由政府資料的公開化，除了促使跨機關資料流通，更能滿足民 眾需求，並強化民眾監督政府的力量。現在智慧型手機時代來臨，需多嶄新的網路、手機服務陸續推 8.
(17) 出，政府公開資料搭上這個順風車，在有限的資料來源之下，善用民間的創意能量，開發出以往政府 難以達成、更加便民的服務內容，創造業者、民眾、政府三贏局面。 依據行政院第3322次院會決議指示 [11]，政府開放資料(Open Data）可增進政府施政透明度、提 升民眾生活品質，滿足產業界需求，對於各級政府間或各部會間之決策品質均有助益可見其重要性， 各部會應自民眾的應用面發想，思考使用端之需求，在規劃時也要考慮到機器讀取介面的必要性。資 料開放的類型以便利及提升民眾生活品質為優先，例如食、醫、住、行、育樂、就業、文化、經濟發 展和生活品質等，期透過政府資料開放，促成跨機關與民間協同合作與服務創新，創造民眾、政府、 業界三贏局面。 依據W3C eGov Interest Group [10]的定義，政府公開資料必須要符合以下原則： 1.. Complete：所以公開資料都可以被取用，不設任何加密或取用權限。. 2.. Primary：資料都是最原始的資料，不是整合、修改過的。. 3.. Timely：資料必須是即時有效的，不是過期的資訊。. 4.. Accessible：資料可以讓任何人、任何單位使用，且可以被拿來做任何可能的應用。. 5.. Machine processable：資料是以可以被電腦、程式理解的格式儲存，使得資料可以被自動化 的存取。. 6.. Non-discriminatory：資料可以被任何人取用，不會有任何取用的權限。. 7.. Non-proprietary：資料室可以同時重複使用，不會互斥存取。. 8.. License-free：資料沒有任何版權、商業法規的限制。但如因部分合理的隱私、機密或特權限 制，則可以有部分版權限制。. 9.
(18) 2.4 鏈結公開資料(Linked Open Data) 鏈結資料(Linked Data)是一種方法，用來發表具有結構的資料。藉由這個方式，資料與資料之間 可以彼此互通，且更能提昇資料的用途與價值。鏈結資料是建構在標準網路技術，例如 HTTP、RDF、 URIs，其用途不是為了開發讓人類閱讀的網頁，而是藉由資料結構化，讓電腦自動可以閱讀，使得 資料本身易於分享、參考。 現今社會早已進入 Web2.0，甚至是往 Web3.0 邁進。對於 Web3.0 的一項討論就是「將網際網路 轉化成資料庫」 [5]，意指散佈在網路的資料，本身具有結構化、電腦可讀等性質，且資料與資料相 互關連，就像網頁般可以容易鏈結、存取。當資料彼此鏈結，並且可讓電腦閱讀，就可以藉由電腦進 行具規模的、自動化的邏輯分析，讓我們可以從來源不同的大量資料，獲得更多有用的資訊。 Tim Berners-Lee 針對 Linked Data，提出了四項標準 [12]： 1.. 使用 URI 描述任何資源或事物. 2.. 使用 HTTP URIs 使得所有的資源可以藉由網路讓使用者存取. 3.. 對於每個 URI 資源提供有用的資訊，並且使用 RDF 或是 SPARQL 標準描述. 4.. 提供連結到其他相關的 URI. Linked Open Data 就是基於 Linked Data 的精神，希望政府、企業在開放資料時，能利用鏈結資料 的方式公開，藉由 Linked Data 的可讀性、易分享性，強化開放資料所帶來的效益。 為了鼓勵資料擁有者，尤其是政府，可以公開資料，Tim Berners-Lee 於 2010 發展了鏈結開放資 料的鑑定準則 [13]。此準則共有五個 Level，Level 越高表示資料越開放、越符合 Linked Open Data 的精神。 1.. 不論格式，以開放授權的方式公開所有資料(此時僅可稱 Open Data)。. 2.. 所有資料是以機器可閱讀的結構化格式發表(例如使用 Excel 取代紙本圖表掃描的圖片)。 10.
(19) 3.. 符合層級二，且使用非授權的資料格式(例如使用 CSV 取代 excel) 。. 4.. 符合以上所有規範，並且使用 W3C 的標準格式(例如 RDF 及 SPARQL)來描述資料，使得人 們可以指向這些資料。. 5.. 符合以上所有規範，並且將資料連結至其他人提供的資料。. 2.5 資源描述架構(RDF) 資源描述架構(Resource Description Framework)及 RDF Schema 是網際網路標準組織(W3C)為解 決資源描述問題的先導規範。RDF 在 2004 年 2 月成為 W3C 標準。 它允許使用者建立階層式的 概念及屬性，因此具有本體的雛型，主要為網路的編碼、資料交換、可供閱讀再使用、機器可了解的 metadata，提供基礎的架構。 RDF 主要是對網際網路上的資源作資訊與狀態的呈現，而它特別適合來表示詮釋資料，並載明 了特定領域的框架(Schema)，以宣告該領域的資源描述語彙，利用此框架表達領域的定義、概念及階 層間的關係，使得該領域的應用將可由語法的層級提昇至語意層級，能讓機器理解及處理，而不喪失 語意的通用框架。 [14] RDF 是建構在 XML 之上，基本模型包含 Resource、Properties、以及 Statement。Resource 有兩 種形態：「URI Resource」以及「Literal Resource」。以圖 2-2 為例，有一個以 URI 描述的 Resource： 『t-shirt』；他有兩個 Properties，分別是『size』及『color』；Properties 的 Value 也算是一種 Resource(基 於 XML 的樹狀結構)；『size』的 Value 是一個 Literal Resource：12；『color』的 Value 是另一個 URI Resource：『white』。. 11.
(20) 圖片 2-2 RDF 範例一. RDF 用來描述物件的基本單位即為 Statement。Statement 描述事情的有三個敘詞：Subject、 Predicate(Property)、以及 Object，通稱三體(triple)。描述方式是：「Subject has a Predicate, which is Object 」。以圖 2-3 的 RDF 為例：. 圖片 2-3 RDF 範例二. . Subject:T-shirt (嚴謹一點應該是<http://www.linkeddatatools.com/clothes#t-shirt>). . Predicate(property):是 Color (嚴謹一點應該是<feature:color>). . Object:white (嚴謹一點應該是<http://www.linkeddatatools.com/colors#white>). 故我們可以用白話文這樣描述： . 『t-shirt』這個物件有個『size』屬性，其值為『12』. . 『t-shirt』有個『color』屬性，其值為『白色』。. 12.
(21) 若以圖像表示，其意涵可用下圖表示；. 圖片 2-4 RDF 關係描述圖. 2.6 SPARQL SPARQL Protocol and RDF Query Language，是一種用於RDF上的查詢語言。SPARQL是基於以前 的RDF查詢語言，例如rdfDB、RDQL、SeRQL，發展而來。此語言師道HP公司語意往研究小組：Jena 開發團隊的支持，用來提供人進行語意網的相關研究和應用開發。2008年1月，SPARQL已經成為W3C 的推薦標準 [15]。. 2.7 Google API Google API，是由谷歌公司開發的應用程式介面。Google的網際網路應用軟體有著非常好的開放 性，針對使用者，Google提供了豐富的產品線；針對應用開發者，Google則為絕大多數產品提供了可 在協力廠商應用中使用整合的API介面 [16]。 Google目前開放的API已經超過60種，這些API的功能非常廣泛，幾乎每一個Google服務就有對應 的API可以呼叫。而這些API常和AJAX、JavaScript、XML或JSON等技術結合。不僅如此，為了讓更 多人使用Google的服務，Google公司也提供了一些不需撰寫程式，只要透過設定就能使用的API小工 具。 本研究主要會使用到以下兩個Google API：. 13.
(22) 1.. Location API：Location API 可以讓你在不需要專注在底層的位置辨別技術的前提下，簡單 的建立你的位置情境感知的應用。而且盡可能的減少對於手機硬體的需求，降低電源損耗。. 2.. Google Calendar API：Google Calendar API 可以讓你建立開發客戶端應用程式，並透過程式 創建、編輯、刪除、搜尋活動(event)。. 14.
(23) 第 3 章 系統規劃. 圖片 3-3-1 系統規劃圖. 本研究可分成兩部分，一部分是使用 RDF 描述台北市公開資料，建立鏈結資料，並提供一個可 以存取的平台；另一部分是利用該平台提供的資訊，實作一個 Context Awareness 的應用服務。 台北市提供各類的 Open Data，資料格式眾多，而且可讀性較差，於是本研究想建立一個 RDF Interface，將政府提供的 Open Data，藉由 Converter 統一轉成 RDF 格式的資料，並且整合不同資料集 的資料，建立起 Linked Open Data，以便達成格式統一的目的，可讀性也較佳，而且藉由鏈結資料的 連結，不同種類的資料彼此可以找到鏈結，方便進行比較、運用。RDF Interface 會提供一個 SPARQL 的 EndPoint，其他使用者可利用 SPARQL 查詢、運用這些資料，開發更多的服務讓一般的使用者使 用。本研究也會以此基礎，開發一個 Context Aware 的行動運用。. 15.
(24) 另一方面，本研究要實作的服務是『停車場資訊的查詢與推撥機制』，藉由這個服務，使用者可 以瀏覽台北市各個汽車停車場的資訊，特別是空位個數，服務中導入情境感知(Context Awareness)的 概念，可以依據使用者的情境，主動提供對應的停車場資訊，讓服務更貼近使用者。本服務的情境感 知會基於 3 種模式：Time-based、Location-based、以及 Event-based，會依據這 3 個資訊作為情境資訊 參考，提供適合的服務。. 3.1 鏈結資料圖(Linked Data Diagram) 台北市政府公開資料，雖然已經提供了許多資料，但是因為資料格式不固定，使得一般使用者難 以進行運用，必須得先做一層分析、整理，才可以加以運用、開發服務。本研究希望能解決這個問題， 本研究採用的方式是：利用RDF，作為資料的儲存格式，取代原本雜亂、可讀性低的資料格式，進一 步可以建立台北市政府公開資料的鏈結資料(Linked Data)，加強資料的擴充性。 Tim Berners-Lee於2009年Ted的演講 [17]提到，政府與企業應該鼓勵開放資料，並且鼓勵建立 Linked Data Graph。2010年在W3C上發佈的「鏈結開放資料的鑑定準則」 [13]，裡頭亦提到，應使用 RDF做為資料描述的標準格式。 本研究試圖使用RDF的方式，描述政府公開資訊，並以此為基礎，提供存取的平台(base on SPARQL)，建立一個方便開發者閱讀、應用的資料格式與開發平台。 觀察台北市公開資料平台的資料，全部 323 筆資料，其中「交通相關」的資料的多達 127 筆，而 其餘的資料，例如「休閒旅遊」、「公共資訊」，也都會需要『地址資訊』，整體看來，大約有 7 成的資料與『地理資訊』相關，所以本研究將以『地理資訊』作為樞紐，建立 Linked Data，試圖把 不同種類、或是不同政府單位的開放資料，鏈結在一起，建構台北市公開資訊的鏈結資料。. 16.
(25) 以下為擷取部分台北市公開資料部分資料所繪出的 Linked Data Diagram：. 圖片 3-2 台北市政府公開鏈結資料圖. 此 Open Data Diagram 有八個資料來源，分別是台北市停車場資訊(Parking Garage)、台北市急救 責任醫院(Emergency)、圖書館資訊(Library)、台北市消防局(Fire Department)、台北市警察局(Police Station)、台北市案件統計(Law Case Record)、台北市社區活動中心(Community)、台北市人口資訊 (Population Info)。這八個資料來源，除了基本的資訊，例如名稱、編號等，屬於 Info 資料，都同時具 備地址、或是行政區域(例如大安區)等 Location 資料，所以我們可以大大利用 Location，作為資料之 間鏈結都樞紐。 本研究為了專注在概念的實作，所以僅使用三種資料來源建立 RDF Interface，分別是：台北市停 車場資訊(交通運輸類，由台北市停車管理工程處提供)、台北市警察局名稱及地址(公共資訊類，由台. 17.
(26) 北市政府警察局提供)、以及台北市政府消防局各單位通訊錄(公共資訊類，由台北市政府消防局提 供)。 本研究試圖使用 RDF 描述這三種資料來源，其建立的 Linked Open Data Diagram 如下：. 圖片 3-3 台北市公開鏈結資料圖. 這個 Diagram 有三個主體： 1.. Parking Garage(停車場資訊). 2.. Fire Department(消防局資訊). 3.. Police Station(警察局資訊). 分別由六個基本單元所組成： 1.. Info：是用來描述基本的資料，例如 Name、ID 等。. 2.. Location：是描述地理資料，其中包含 Address、Latitude、Longitude...等。. 3.. Time：是描述服務時間/營業時間。. 4.. Contact：是電話、傳真等資訊。 18.
(27) 5.. Police：記錄著警局的隸屬關係。. 6.. Context：則是因應情境感知應用所使用的資料，不屬於台北市公開資料的一部分。裡 面記錄 CtxParkingHour(預計要停車的時間)、CtxArea(預計要停車的行政區)、以及 Priority(優先權)。. 以下是各個 Dataset 的 Data Schema： 表格 3-1 Data Schema - information xmlns:info=”http://data.taipei.gov.tw/information#” Attribute Name info:id. Data Type Long. Description 該筆資料的唯一識別. info:name info:type. String String. 該筆資料的名字 該筆資料的屬性。其項目有： context, parking, police, fire_department. 表格 3-2 Data Schema - location xmlns:loc=”http://data.taipei.gov.tw/location#” Attribute Name loc:area. Data Type String. loc:adderss loc:latitude loc:longitude. String Double Double 表格 3-3. Description 區域資訊。其項目為台北市所 有行政區域 地址資訊 緯度資訊 經度資訊. Data Schema - time. xmlns:time=”http://data.taipei.gov.tw/time#” Attribute Name time:start time:end. Data Type String String 表格 3-4. Description 服務開始時間 服務結束時間. Data Schema - parking. xmlns:pa=”http://data.taipei.gov.tw/parking#” Attribute Name pa:total_car. Data Type Integer. pa:available_car. Integer. Description 停車場車位總數 停車場空位總數 19.
(28) 表格 3-5 Data Schema - contact xmlns:con=”http://data.taipei.gov.tw/contact#” Attribute Name con:tele con:fax. Data Type String String. Description 服務處電話號碼 服務處傳真號碼. 表格 3-6 Data Schema - police xmlns:police=”http://data.taipei.gov.tw/police#” Attribute Name police:content. Data Type String. Description 警局所屬單位. 表格 3-7 Data Schema - context xmlns:ctx=”http://xml.csie.ntnu.edu.tw/context” Attribute Name ctx:priority. Data Type Integer. ctx:parking_hour ctx:area. Integer String. Description 優先權設定 (預計)停車時間 (預計)停車行政區. 以下是三個主要單元的 Data Schema。 表格 3-8 Data Schema – 停車場資訊 一個停車場資訊 Attribute Name info:id info:name info:type. Data Type Long String String. loc:adderss loc:area. String String. loc:latitude loc:longitude time:start time:end pa:total_car. Double Double String String Integer. Description 該筆資料的唯一識別 該筆資料的名字 該筆資料的屬性。其值 為:parking 地址資訊 區域資訊。其項目為台北市所 有行政區域 緯度資訊 經度資訊 服務開始時間 服務結束時間 停車場車位總數. 表格 3-9 Data Schema – 停車場即時空位資訊 一個停車場的即時空位資訊 Attribute Name. Data Type. Description 20.
(29) info:id pa:available. 該筆資料的唯一識別 停車場空位總數. Long Integer. 表格 3-10 Data Schema – 警察局資訊 警察局資訊 Attribute Name info:id info:name info:type loc:adderss loc:area. Data Type Long String String String String. Description 該筆資料的唯一識別 該筆資料的名字 該筆資料的屬性。其值為:police 地址資訊 區域資訊。其項目為台北市所 有行政區域. police:content. String. 警局所屬單位. 表格 3-11 Data Schema – 消防局資訊 消防局資訊 Attribute Name info:id info:name info:type. Data Type Long String String. loc:adderss. String. loc:area. String. con:tele con:fax. String String. Description 該筆資料的唯一識別 該筆資料的名字 該筆資料的屬性。其值 為:fire_department 地址資訊 區域資訊。其項目為台北市所 有行政區域 服務處電話號碼 服務處傳真號碼. 表格 3-12 Data Schema – 情境資訊 情境資訊 Attribute Name info:id. Data Type Long. Description 該筆資料的唯一識別. info:type. String. ctx:priority ctx:parking_hour ctx:area. Integer Integer String. 該筆資料的屬性。其值 為:context 優先權設定 停車時間 停車行政區. 特別的是，實際上停車場資訊被分成兩個 RDF Dataset，理由是為了要能將空位資訊進行分析預 測，所以特別幫該資訊獨立成單獨的 RDF Dataset。實作時，會依據給定的時間點，把對應的空位個 21.
(30) 數資訊整合成完整的停車場資訊，再進行 Query。. 3.2 情境感知(Context Awareness) 我們希望利用手機的 Sensor，即時獲得使用者的「時間資訊」以及「地理資訊」，並且以此為基 礎，提供符合此情境的運用。基於上述規劃的 Linked Data Diagram，我使用的是『停車場資訊』開發 情境感知行動應用。在這個應用中，使用者的時間、位置資訊會傳送給 Server，Server 依據此情境， 提供符合的停車場資訊。例如：使用者下午 3 點要去台北 101 開會，則服務會提供位於信義區的停車 場資訊以及該停車場下午 3 點的空位資訊。 本研究會實現兩種模式的情境感知應用，分別是『依據情境規則』以及『依據 Calendar Event』。. 圖片 3-4 情境規則系統模式圖. 首先是『依據情境規則』模式，我們會建立一個 Context Management 系統，讓使用者設定自己 的『情境規則』。這裡的『情境規則』設定，就是實踐基於 Time-based 及 Location-based 的情境感知 服務。當系統進行情境感知搜尋的時候，會依據該設定，推播想要的消息。這裡規劃三種情境規則： i.. 設定『地區』：只要使用者情境符合該地區，就會依據該地區，配合目前的時間，提供適合 的資訊。例如：上午 11 點位於『大安區』，會推薦 11 點的大安區停車場資訊。. ii.. 設定『時間』 ：只要符合使用者情境符合該時間，就會依據該時間，配合目前使用者的區域， 提供適合的資訊。例如：『上午 11 點』位於文山區，會推薦 11 點的文山區停車場資訊. iii.. 設定『時間』與『地區』 ：使用者情境必須要同時符合『時間』及『地區』 ，才會提供適合的 資訊。例如：『上午 11 點』且位於『信義區』，會推薦 11 點的信義區停車場資訊。. 22.
(31) 『依據Calendar Event』模式提供了第三種情境：Event-based，希望由特定的「事件」驅動服務， 而本研究採用的是Google Calendar的事件(Event)。藉由讀取行事曆的事件，推斷使用者情境，提供符 合的服務。所以當我們讀取到行事曆的事件時，會試著讀取該事件發生的「地點」及「時間」，並且 傳送給Server，系統會在適當的時機，將符合情境的停車場資訊，推薦給使用者。. 3.3 空位資訊預測 政府提供停車場資訊時，分成兩個部分，一份是「停車場描述」，另一份是「停車場即時空位資 訊」。「停車場即時空位資訊」是目前各個停車場的空位總數，也是這份公開資料最有值得參考的部 份。可惜的是，我們無法從這份公開資料中，得到特定時間點的空位個數。例如使用者下午3點在信 義區開會，但我無法事先知道該時間點，信義區停車場的空位個數為何。 於是，本系統會建立一個預測機制，記錄過去各個停車場的空位歷史資料，並加以分析，導出一 個停車場空位模型，以便讓使用者能夠得到任一時間、任一停車場的空位數目。 本研究使用的是線性組合預測法(Linear Combination of Forecasting)。我利用目前的空位預測值， 以及實際空位個數，求出新的預測值，其公式如下：. A new p A now (1 p) A Anew：新預測出的空位個數 Anow：目前的預測空位個數 A：目前的實際空位個數，從台北市公開資料所得知 p：值為 0~1 的參數，用來調整舊預測值與即時空位數的比例. 23.
(32) 本算法有兩個變數：『目前的預測空位個數』、『實際空位個數』；有一個操縱變因：p，作為 調整兩變數對於預測值的影響比例。 本算法是線性相依的預測法(Linear Dependent)，也就是說兩變數對於新預測值有相依性。這個預 測法顯示一個意義：『目前空位預測值』與『實際空位數』對『新預測值』同時具有影響，且影響是 成反比的。如果我們希望『目前預測值』對於『新預測值』有較大的影響，則可以調整 p 值越大越好； 如果希望『實際空位數』對『新預測』值有較大的影響，則 p 值越小越好。 以下是利用同樣的算法，配合不同 p 值，所做的試算： 第一個試算，令 p 值為 0.2，空位預測值設定為 10，經過 6 個單位時間後，其預測值的變化如下 圖： 表格 3-13 空位資訊預測試算表一 Time 1 Time 2 Time 3 Time 4. Time 5. Time 6. 目前空位預測值. 10. 14. 18. 24.4. 20.88. 8.976. 實際空位個數. 15. 19. 26. 20. 6. 21. 新預測空位個數. 14. 18. 24.4. 20.88. 8.976. 18.5952. 空位個數 26 24.4 21 18.5952. 20.88 20. 19 18 15 14. 8.976 6. 1. 2. 3. 4. 5. 6. 圖片 3-5 空位個數趨勢圖一. 利用圖表觀察，可以發現預測空位個數受到實際空位個數的影響很大，如果實際空位個數的起伏 大，則預測結果的起伏也會較大。 24.
(33) 第二個試算，令 p 值為 0.8，空位預測值設定為 10，經過 6 個單位時間後，其預測值的變化如下 圖： 表格 3-14 空位資訊預測試算表二 Time 1. Time 2. Time 3. Time 4. Time 5. Time 6. 目前空位預測值. 10. 11. 12.6. 15.28. 16.224. 14.1792. 實際空位個數. 15. 19. 26. 20. 6. 21. 新預測空位個數. 11. 12.6. 15.28. 16.224. 14.1792. 15.54336. 空位個數 26. 11. 16.224. 15.28. 15. 21. 20. 19 12.6. 14.1792. 15.54336. 6. 1. 2. 3. 4. 5. 6. 圖片 3-6 空位個數趨勢圖二. 利用圖表觀察，可以發現預測空位個數受到實際空位個數的影響很大，如果實際空位個數的起伏 大，則預測結果的起伏也會較大。 如此，我們可以依據我們的需要，調整 p 值，使得預測結果可以更符合實際需求。未來如果要加 強預測的準度，則可以針對預測演算法加以改進，系統其他部分及其架構都不會受影響。. 25.
(34) 3.4 使用案例圖(Use Case Diagram). 圖片 3-7 使用案例圖. 這個系統有兩個Actor，一個是「一般使用者」，一個是「情境感知系統」。有四個案例：「瀏 覽合適停車場」、「主動推薦合適停車場」、「Rules新增/刪除/查詢」、「分析空位資訊」： 1.. 瀏覽合適停車場：此系統提供最基本的瀏覽功能，使用者可以利用系統，依照需求直接瀏 覽任一時間點、任一台北市停車場資訊。. 2.. 主動推薦合適停車場：使用者可以設定情境規則，當使用者的情境資料符合設定的規則， 系統就會「主動推撥」適合的停車場資訊。「主動」的意思是，使用者不用開啟應用程式， 就會利用Android手機的推撥機制，將訊息推薦給使用者。例如：使用者期望能知道公司 附近(信義區)上班時間(8點)的附近停車場空位訊息，當時間接近8點，使用者開車進入信 義區附近，系統就會主動推撥最多空位的停車場，呈現在Android手機的通知列，使用者 不用再自己瀏覽、搜尋。 26.
(35) 3.. Rules新增/刪除/查詢：使用者可依據自己的期望，自由的設定自己情境規則，也可以隨時 瀏覽、刪除這些情境規則。. 4.. 分析空位資訊：系統會持續追蹤台北市停車場即時空位資訊，並且將其資料加以分析，以 建立停車場空位預測模型。. 3.5 活動圖(Activity Diagram) 根據 Use Case Diagram 的各個案例，歸納出數個 Activity Diagram。以下分別介紹。. 3.5.1 瀏覽合適停車場. 圖片 3-8 活動圖 – 瀏覽合適停車場. 27.
(36) 1.. 使用者進入系統. 2.. 選擇篩選的條件。本系統有兩個參數可以選擇：「區域」以及「時刻」。「區域」是指台北 市的各個行政區，使用者可以選擇瀏覽特定行政區的停車場資訊，或是選擇全部瀏覽；「時 刻」是以『小時』為單位，可以瀏覽0~23時，不同時刻的停車場資訊，包括空位資訊。因為 本系統已經建立好空位預測模型，所以即使不是當下的時刻，抑或是當台北市政府公開資訊 進行維修時，本系統仍然可以提供自己預測的各個停車空位個數，確保服務的進行。. 3.. 傳送情境資料給Server. 4.. Server依據該條件搜尋符合的停車場. 5.. 將結果傳回至使用者Device. 6.. 呈現在螢幕上。. 28.
(37) 3.5.2 使用者瀏覽情境設定. 圖片 3-9 活動圖 - 使用者瀏覽情境設定. 1.. 使用者進入系統. 2.. 打開瀏覽情境規則的頁面. 3.. 向Server要求目前所有設定的情境規則. 4.. Server找出所有的情境規則. 5.. Server將所有的情境規則回傳給使用者. 6.. 呈現在螢幕上。. 29.
(38) 3.5.3 使用者新增情境規則. 圖片 3-10 活動圖 – 使用者新增情境規則. 1.. 使用者進入系統。. 2.. 選擇情境規則，分別是「區域」以及「時間」。. 3.. 把規則傳送至Server儲存。關於Rules的儲存也是以RDF的格式記錄，以方便與其他公開資料 整合、搜尋。. 4.. Server儲存好後，傳送確認訊息。. 5.. 使用者Device收到確認訊息，更新畫面，呈現目前所有設定的Rules。 30.
(39) 3.5.4 使用者刪除情境規則. 圖片 3-11 活動圖 – 使用者刪除情境規則. 1.. 使用者進入瀏覽情境規則的頁面。. 2.. 選擇一則欲刪除的Rule。. 3.. 傳送該則Rule的刪除訊息至Server。. 4.. Server移除該筆Rule。. 5.. 回傳確認訊息，Device確認刪除，更新畫面，呈現目前的情境規則。 31.
(40) 3.5.5 系統主動推薦 – 依據情境規則. 圖片 3-12 活動圖 – 系統主動推薦(依據情境規則). 32.
(41) 「主動推薦合適停車場」的案例，可以分成兩個狀況： 「依據情境規則」 、 「依據 Calendar Event」。 這裡討論「情境規則」的 Activity。 1.. 每隔一固定時間，會背景執行此process。. 2.. 使用者的Device讀取目前的「位置」及「時間」資訊. 3.. 傳送至Server. 4.. Server會整合使用者設定的情境規則，以便進行判斷。. 5.. 檢查是否有符合使用者目前情境的規則。如果有，則針對該情境進行搜尋。. 6.. 回傳結果。. 7.. Device確認是否有有效的結果。. 8.. 如果有，啟動Notification系統，通知使用者瀏覽；否則就不做任何事。. 33.
(42) 3.5.6 系統主動推薦 – 依據 Calendar Event. 圖片 3-13 活動圖 – 系統主動推薦(依據 Calendar Event). 34.
(43) 1.. 每隔一固定時間，會背景執行此process。. 2.. 讀取Google Calendar資訊，判斷是否有有用的Event資訊。如果沒有，則停止Activity。. 3.. 把該Event的Location(行政區域)與Time資訊傳送至Server。. 4.. Server依據該資訊，找出合適停車場。. 5.. 回傳結果。. 6.. Device收到回傳，啟動Notification系統，通知使用者瀏覽。. 針對第二點「判斷是否有有用的Event資訊」，再此特別說明。 因為每個人設定Event的方式與描述不一定相同，所以我會先判斷是否能從Event中得到可用的資 訊。判斷規則如下： i. 先抓取所有Google Calendar的Event，並且過濾還沒發生的Event。 ii. 擷取所有未發生的Event中，離現在最接近的Event。 iii. 確認最接近的Event，距離現在的時間小於2小時(時間差太多就沒有提醒的意義)。 iv. 確認該則Event有Location資訊，並且可從Location資訊得知位於台北市的哪個行政區。 v. 如果該則Event沒有Location資訊，則抓取Title資訊，並且可從Title資訊得知位於台北市的哪個 行政區。 vi. 以上如有任一規則不符合，則判斷沒有可用的Event資訊。. 35.
(44) 3.5.7 分析空位. 圖片 3-14 活動圖 – 分析空位. 1.. 每隔固定時間，執行此Process。. 2.. 向台北市政府公開資訊平台讀取即時停車場空位資訊。. 3.. 納入預測模型。. 36.
(45) 第 4 章 系統開發與實作 4.1 系統架構. 圖4-1 圖片 4-4-1 系統架構. 這是實際開發的系統架構。系統分兩部分，Server端及Client端。Server端主要有三個部分：Search Engine、Context Rule Management。 I.. Search Engine：可細分兩部分Query System & Parking Info Integrator。 i.. Query System：就是Linked Open Data的Query介面，可以讓我們存取「警察局資訊」、 「消防局資訊」、以及「停車場資訊」等台北市的公開資料；本應用僅會利用到「停車. 37.
(46) 場資訊」。因為所有的資料已經事先處理成RDF格式，所以Query System是使用SPARQL 進行資料存取。Query System也會整合Context Rule資訊，以提供情境感知服務。 ii.. Parking Info Integrator：實作時，停車場資訊會分成兩部分：『停車場描述』、以及『停 車場空位預測個數』，一個停車場會有24個停車場空位個數，例如上午9點空位預測個 數為X、上午10點空位預測個數為Y…。實作時會先依據給定的時間，擷取正確的空位 資訊，再利用Parking Info Integrator整合出完整的停車場資訊(包含完整的停車場描述以 及該時的空位預測值)。. II.. Context Rule Management：用來管理使用者的情境規則，並且將這些資料整合至Search Engine 處理。. III. Available Analysis：其功能是分析空位資訊。該系統會持續向台北市公開資料要求目前的空 位資訊，並且將預測模型結果儲存在Available.rdf。 IV. JSON Converter：為了降低流量的大小、以及顧及開發上的方便，在傳輸資料前，會將資料 打包成JSON再送出。 Client端，也就是使用者的Android Device，主要功能有三項：提供使用者介面讓使用者瀏覽停車 場資訊、存取情境規則、提供背景查詢並推撥。 I.. 瀏覽停車場資訊：提供基本的瀏覽功能，使用者可以選擇任一時間、任一行政區，觀看符合 需求的停車場資訊。. II.. 存取情境規則：可以瀏覽設定的情境規則，並且隨時新增、刪除任一則情境規則。. III. 提供背景查詢並推撥：Android 系統有提供一個功能：『Service』，即便在 Application 主體 沒有開啟，也可以在手機背景執行一段程式。在這裡我使用 Service 的功能，在背景執行一. 38.
(47) 個計時器(timer)，每隔一段時間，便執行「主動查詢」的功能。主動查詢分成兩個部分：情 境規則搜尋、Google Calendar Event 搜尋 i.. 情境規則搜尋：將使用者目前所在的區域與時間傳送至 Server，此時會將情境規則納入 Query System，判斷是否有符合使用者區域與時間的情境規則，如果有符合，再 Query 該區域與該時間的停車場資訊，傳回給使用者。使用者 Device 收到 Query 結果，會啟 用 Android 的另一個功能：『Notification』，把該則訊息以提示的方式，呈現在螢幕上 方的通知列，以達到主動推撥的效果。. ii.. Google Calendar Event 搜尋：先讀取使用者的 Google Calendar 資訊，並過濾出可用的 Event 資訊，將該 Event 的區域、時間資訊上傳至 Server，交由 Query System 進行搜尋， 搜尋結果傳回使用者 Device，一樣利用『Notification System』通知使用者，達到主動 推撥的功能。. 39.
(48) 4.2 類別圖(Class Diagram). 圖片 4-2 類別圖. 這是Server端的Class Diagram，為了將各個資料模組化，所有使用的資料都有加以封裝。 1.. DataSet：最基本的資料結構，儲存著很基本的資訊，例如：ID、Type、以及Name。其功能 只有基本的Setter與Getter。. 2.. OpenDataSet：繼承自DataSet的資料結構。就如第三章所說，我們會使用Location資料當做不 同公開來源資料的樞紐，也就是說，所有的公開資料理應都會具有Location的訊息，於是在 這資料結構新增了兩個參數：Address和Area。. 40.
(49) 3.. 為了讓橋接SPARQL Query的結果，所以建立了一個getInstance的操作，讓此物件可以具 Query的結果，建立對應的物件，所有的子類別也都會繼承這項操作。. 4.. ParkingGarage：繼承自OpenDataSet，且額外增加了記錄停車場資訊的參數，例如：Latitude、 Longitude、TotalCar(車位總數)、AvailableCar(空位個數)。. 5.. FireDepartment：繼承自OpenDataSet，額外增加聯絡資訊，包含Tele、Fax。. 6.. PoliceStation：繼承自OpenDataset，額外增加隸屬資訊。. 7.. Context：繼承自DataSet，且額外增加因應本研究的情境感知服務所需要的資訊，包含： CtxArea(預計要停車的行政區域)、CtxParkingHour(預計要停車的時間)、Priority(該筆情境規 則的優先權)。. 8.. Context Management：用來處理情境規則的類別，不記錄額外的資訊。Context Management 與Search Engine有相依性，因為Search Engine會使用到Context Management的操作；Context Management一次可能會有0到多個Context Object。. 9.. Search Engine：用來處理SPARQL Query的類別，不記錄額外的資訊。Search Engine各自可 能會有0到多個PoliceSation、ParkingGarage、以及FireDepartment Object。. Client端基本是所有的Data都需要從Server端獲取，其資料架構也沿襲Server的設計。. 4.3 循序圖(Sequence Diagram) 以下針對各個Activity實作的Sequence進行解說。. 41.
(50) 4.3.1 瀏覽停車場. 圖片 4-3 循序圖 – 瀏覽停車場. 此活動是由使用者所驅動。使用者選擇變數，也就是『區域』以及『時間』，Device就會送出查 詢訊息。為了不要造成使用者使用不便，以及維護Device的畫面順暢，查訊的動作是採取「非同步」 的方式。Search Engine會依據『時間』，整合出有「該時刻空位資訊」的停車場訊息，然後依據『區 域』進行查詢。把結果回傳給Android Device，Device便會重整畫面，呈現使用者想看的停車場資訊。. 42.
(51) 此時使用者可以點選任一停車場，觀看詳細的停車場資訊及地圖資訊，並且可以啟動Google Map導航 功能。. 4.3.2 查詢情境規則. 圖片 4-4 循序圖 – 查詢情境規則. 此活動由使用者驅動。使用者欲瀏覽目前所有設定好的情境規則，於是向Android Device送出要 求，Device便會向Context Management要求目前所有的規則。為了不要造成使用者使用不便，以及維 護Device的畫面順暢，查訊的動作是採取「非同步」的方式。Context Management收到要求，便直接 將目前所有的情境設定回送給Device。Device收到，更新使用者畫面，呈現所有接收的情境規則，讓 使用者瀏覽。. 43.
(52) 4.3.3 新增情境規則. 圖片 4-5 循序圖 – 新增情境規則. 此活動由使用者驅動。使用者輸入新的情境規則(『時間』及『區域』)，Device便會像Context Management送出「新增要求」。Context Management新增該筆規則後，會回傳「確認訊息」，Device 確認到底是否新增成功，一旦確認，會顯示成功訊息，並且向Context Management要求目前的所 有規則，呈現在螢幕上。如果新增失敗，則會顯示失敗訊息。 44.
(53) 4.3.4 刪除情境規則. 圖片 4-6 循序圖 – 刪除情境規則. 此活動由使用者驅動。使用者選擇要刪除的情境規則，Device便向Context Management發出請求。 Context Management依照要求刪除該則規則，並回傳「確認訊息」。Device確認刪除成功，會顯示成. 45.
(54) 功訊息，並且向Context Management要求目前的所有規則，呈現在螢幕上。如果新增失敗，則會顯示 失敗訊息。. 4.3.5 主動搜尋 – 情境規則搜尋與推播. 46.
(55) 圖片 4-7 循序圖 – 主動搜尋(情境規則搜尋與推播). 此活動由Android Device開始，是由持續在Android背景執行的『Timer』所驅動。啟動後，利用 Android提供的Sensor，配合Google Geocoding API，獲得使用者目前的『時間』及『區域』 ，上傳給 Search Engine進行判斷。Search Engine會依據『時間』，整合出有「該時刻空位資訊」的停車場訊息。 接者Search Engine會向Context Management要求目前的情境規則，以便進行情境感知搜尋。用獲得的 情境資訊：『地區』、『時間』作為key，檢查所有設定的情境規則，是否有任一則符合使用者的情 境資訊，如果有符合，就會依據該情境進行Query。例如一則情境規則為：「13點時，大安區」，而 獲得的使用者情境正好符合這兩項，則會找出位於大安區的停車場，並且包含13點時的空位預測資訊。 不論是否有符合的情境，都會把結果回傳給Device。Device判斷回傳結果是否有包含推薦的停車場資 訊，如果沒有，就不做進一步的行為；如果有，則會將利用Notification通知使用者。使用者如果看到， 可以點擊通知，瀏覽所推薦的停車場、甚至進行導航。. 47.
(56) 4.3.6 主動搜尋 – Calendar Event 搜尋與推播. 圖片 4-8 循序圖 – 主動搜尋(Calendar Event 搜尋與推播). 48.
(57) 此活動由Android Device開始，是由持續在Android背景執行的『Timer』所驅動。啟動之後，會 去讀取使用者的Google Calendar，並且判斷是否存在有效的Event。如果沒有，則不做進一步動作； 如果有，就會擷取Event的『地區』、『時間』資訊，上傳至Search Engine判斷。Search Engine依據『時 間』，整合出有「該時刻空位資訊」的停車場訊息。接者就針對『地區』，取得該『地區』的停車場， 並且將結果回傳。Device收到回傳，利用Notification通知使用者。使用者如果看到，可以點擊通知， 瀏覽所推薦的停車場、甚至進行導航。. 4.4 實作畫面 4.4.1 瀏覽停車場與導航 使用一進入 App 就是停車場瀏覽畫面，點擊畫面左上角可以選擇時間以及區域。. 圖片 4-9 瀏覽停車場/選擇時間與區域. 49.
(58) 使用者點擊其中一個停車場，可以觀看該停車場的訊息。點擊右上方的『NAVI』 ，可以呼叫Google Map進行導航。. 圖片 4-10 觀看停車場訊息，並且啟動導航. 50.
(59) 4.4.2 瀏覽、新增情境規則 使用者可以瀏覽目前所設定的情境規則。點擊有上角的『ADD』 ，可以新增情境規則，確認規則 之後按『COMMIT』即可完成新增。. 圖片 4-11 瀏覽情境規則，新增情境規則. 51.
(60) 4.4.3 系統主動推薦 依據情境規則或是Canledar Event，推薦合適停車場。推薦結果顯示在系統通知列(Notification)。 點擊通知可進行瀏覽。. 圖片 4-12 系統主動推薦，瀏覽推薦. 52.
(61) 第 5 章 結論與未來發展 5.1 結論 本研究為了能讓台北市政府公開資料能靈活運用，激發更多的價值，採用 Tim Berners-Lee 於 W3C 所制定的鏈結開放資料分類鑑定準則，使用 RDF 去描述來自不同單位、不同種類的資料，並且建立 Linked Open Data Diagram，讓資料的格式更加統一，使得開發者能更容易運用，並且藉由彼此的鏈 結，資料交互運用。本研究以『地理資訊』做樞紐，讓資料即可以相互連結，實現了跨資料及的搜尋， 同時瀏覽警察局、消防局、以及停車場資訊等三種不同資料集的資料。依據這項鏈結開放資料分類鑑 定準則，台北市政府公開資料的開放水準，可以由三顆星(使用非授權的資料格式，例如 CSV)上升至 四顆星(使用 W3C 的標準格式，例如 RDF，來描述資料)。 過去的網路世界，大家著重在「資料呈現」，比較少琢磨在「資料本身」。最近 Big Data 概念甚 行，大家開始重視資料本身所蘊含的力量，此時遇到了「資料散亂」、「格式不一」的問題。Linked Data 是一個很有意思，且很有效方法，讓大家能重新正規化資料，讓資料格式統一，並透過鏈結關 係，可以連接到其他更多的資訊。全球已經陷入了資料爆炸的局面，藉由資料的重整，我們可以更方 便的釐清、挖掘資訊，進而改善我們的社會。 此外，本研究也探討了情境感知應用。本研究以智慧型手機作為載具，提供 Location-based、 Time-based、以及 Event-based 的情境應用。當科技不斷的進步，人人身上都有高強運算的智慧型手 機，開發者的應用也應該能繼續往使用者面相延伸，藉由理解使用者的情境，提供對應服務，讓應用 更具有智慧。. 53.
(62) 5.2 未來發展 本論文使用台北市政府公開資料提供的部份資料(包含台北市停車場資訊、台北市警察局名稱及 地址)、以及台北市政府消防局各單位通訊錄)，建立對應的 Linked Data Diagram，並且開發 RDF Interface，提供應用程式作為開發平台。雖然所蘊含的資料種類以及資料個數並未特別多，但是已經 能夠充分感受到透過資料 RDF 化、建立 Linked Data Diagram 所帶來的力量以及潛力，例如存取方便、 格式不再混亂、多元存取…等等。未來可以將更多台北市政府所提供的公開資料，進一步正規化，建 立一個更完整的台北市 Linked Data Diagram，讓更多的資料，以更容易的方式讓市民運用。除此之外， 也期待藉由台北市政府公開資料的鏈結效果，可以跟其他縣市政府單位的開放資料進行連結，建立一 個全國公開資料的資料網路。甚至，期待本研究的 Linked Data Diagram，能夠跟網路上更多的 Lined Data 相互關聯，帶來更有力量的資訊運用。 情境感知也會是未來幾年的發展方向，除了本論文所提出的三個情境感知方向，還有很多的可能 性，例如 Activity-based(基於使用者活動的感知應用)，期待藉由更多的智慧型手提裝置、智慧型穿戴 裝置，開發者能發想更多創意，提供更多面相的情境感知服務。. 54.
(63) 第 6 章 參考文獻 [1] 蘇文彬, “Google：台灣智慧型手機普及率已達 51%,” iThome, 2013. [2] 臺北市政府, “臺北市政府資料開放平台,” 9 2011. [線上]. Available: http://data.taipei.gov.tw/opendata. [存取日期: 24 11 2013]. [3] 國家發展委員會, “政府資料開放平台,” 29 4 2013. [線上]. Available: http://data.gov.tw/. [存取日 期: 24 11 2013]. [4] Wikipedia, “開放資料,” [線上]. Available: http://zh.wikipedia.org/wiki/%E9%96%8B%E6%94%BE%E8%B3%87%E6%96%99. [存取日期: 24 11 2013]. [5] “Web 3.0,” 2013. [線上]. Available: http://zh.wikipedia.org/wiki/Web_3.0. [存取日期: 5 2014]. [6] Wikipedia, “DBpedia,” 5 2014. [線上]. Available: http://en.wikipedia.org/wiki/DBpedia. [存取日 期: 5 2014]. [7] Schilit, B.N. and Theimer, M.M., “Disseminating Active Map Information to Mobile Hosts,” 於 IEEE Network 8, 1994. [8] B. Schilit, N. Adams, and R. Want., “Context-aware computing applications,” 於 IEEE Workshop on Mobile Computing Systems and Applications, Santa Cruz, CA, US., 1994. [9] 郭子瑜, “無所不在的個人化情境感知服務,” 數位典藏與學習電子報, 2011. [10 W3C(e-Gov), “eGovernment at W3C - Better Government Through Better Use of the Web.,” [線 ] 上]. Available: http://www.w3.org/egov/. [存取日期: 4 3 2014]. [11 國家發展委員會, “政府資料開放平台 - 關於我們,” [線上]. Available: http://data.gov.tw/about. ] [存取日期: 4 3 2014]. [12 “Linked data,” 2014. [線上]. Available: http://en.wikipedia.org/wiki/Linked_data. [存取日期: 5 ] 2014]. [13 “Linked Data - Design Issues,” 2009. [線上]. Available: ] http://www.w3.org/DesignIssues/LinkedData.html. [存取日期: 5 2014]. [14 王梅玲, “資源描述架構/資源描述綱要,” 4 2011. [線上]. Available: ] http://techserviceslibrary.blogspot.tw/2011/04/rdf-resource-description.html. [存取日期: 5 2014]. [15 W3C, “SPARQL is a Recommendation,” 2008. [線上]. Available: ] http://www.w3.org/blog/SW/2008/01/15/sparql_is_a_recommendation/. [存取日期: 5 2014]. [16 Wikipedia, “Google API,” [線上]. Available: http://zh.wikipedia.org/wiki/Google_API. [存取日期: ] 2 12 2013]. [17 T. Berners-Lee, “Tim Berners-Lee: The next web | Talk Video | TED.com,” 2009. [線上]. Available: ] http://www.ted.com/talks/tim_berners_lee_on_the_next_web#t-182417. [存取日期: 5 2014]. [18 Julia Hoxha and Armand Brahaj, "Open Government Data on the Web: A Semantic Approach," in ] Emerging Intelligent Data and Web Technologies (EIDWT), 2011 International Conference on, 2011. [19 Alexandre Lopes Machado and Jos´e Maria Parente de Oliveira, "DIGO: An Open Data Architecture for 55.
Outline
相關文件
In this section we define a general model that will encompass both register and variable automata and study its query evaluation problem over graphs. The model is essentially a
Following the supply by the school of a copy of personal data in compliance with a data access request, the requestor is entitled to ask for correction of the personal data
Responsible for providing reliable data transmission Data Link Layer from one node to another. Concerned with routing data from one network node Network Layer
Discovering the City by Mining Diverse and Multimodal Data Streams – IBM Grand Challenge: New York City 360. § Exploring and Integrating Multiple Contents and Sources for
The remaining positions contain //the rest of the original array elements //the rest of the original array elements.
•It directly models prior semantic knowledge units, which enhances the ability to learn semantic representation?. • ERNIE learns the semantic representation of complete concepts by
Furthermore, in order to achieve the best utilization of the budget of individual department/institute, this study also performs data mining on the book borrowing data
In the development of data acquisition interface, matlab, a scientific computing software, was applied to acquire ECG data with real-time signal processing.. The developed
