結合動態情境資料分析之鏈結開放資料應用研究

全文

(1)國立台灣師範大學資訊工程研究所碩士論文. 指導教授：林均翰博士共同指導：葉耀明博士. 結合動態情境資料分析之鏈結開放資料應用研究 Research on Linked Open Data Applications Using Dynamic Context Data Analysis. 研究生：余建穎撰中華民國 105 年 6 月.

(2) 摘要結合動態情境資料分析之鏈結開放資料應用研究余建穎政府開放資料現今在各國漸漸盛行，從 2009 年美國和英國政府開放資料平台上線後，各個國家開始發展自有的政府開放資料平台。臺灣也不例外，臺北市政府首先推動台北市開放資料平台，給予民眾應用或資料查詢開發使用。但綜觀目前台灣各區的開放資料，雖然蘊含了各領域的大量資料，但卻遇到許多窘境，其中包含格式雜亂、格式不容易整合應用、資料授權複雜...等問題，使得民眾或開發者針對這些資料不易應用與開發服務。本研究利用鏈結資料概念來用於開放資料上形成鏈結開放資料應用，透過統一轉換成 RDF 格式來描述資料並加以進行鏈結於雜亂資料中相互關係來增強資料可讀性和可行性，能使資料更容易被使用，開發上也更具有彈性。本研究利用臺北市的地理位置為情境感知的鏈結基礎，利用行動裝置定位功能，於臺北市開放資料平台中採用交通類別的停車場、微笑單車以及捷運形成鏈結開放資料集，再利用開放資料於時間軸上數據分析和列車到站時間計算，讓使用者能透過當下地理位置以及自行設定條件進行查詢、計算與服務整合串聯成由開車、停車、租借微笑單車以及搭乘捷運列車，進一步地搭配旅遊景點的動態情境資料分析或自行設計一套專屬於自己的客製化一日遊行程的情境分析應用。. 關鍵字：政府開放資料、鏈結開放資料、動態情境資料分析 i.

(3) Abstract Research on Linked Open Data Applications Using Dynamic Context Data Analysis Chien-Ying Yu Many countries has been developed their own open government data platform after Data.gov.(England) and Data.gov.(America) platform have been lunched since 2009. Government data platform has been established in each country, including Taiwan. Taipei City Government is the first local government which promotes the Taipei open data platform first and provides people to use this platform. Although there are amounts of data about various areas in the open data of Taiwan, it faces many data format problems including inconsistency, licensing etc. This research uses the concepts of linking open data to analyze correlated open data via semantic web technology. The linking open data are transformed to an RDF (Resource Description Framework) format to enhance the readability and systematic development. Besides, our system provides a semantic web access interface which can enhance the usability of data. We develop a location-based context-aware service based on Taipei city open data to provide various smart city services. Through the integration of parking lots, public bicycle and MRT data, users can use their mobile devices to arrange activities according to the location of dynamic context data analysis and set their own requirements to design a one-day-traveling schedules.. Keyword：open government data, linked open data, dynamic context data analysis ii.

(4) 誌謝歷經兩年不斷地努力學習，透過持續討論的建議以及修改實作與內容，終於完成研究和撰寫這份論文，在此由衷地感謝葉耀明及林均翰教授研究的過程中教導與鼓勵，也很開心能在研究所中參加全國大專校院資訊應用服務創新競賽中獲得佳作，增加自己的人生歷練與台上報告的技巧，也在競賽中尋找出自己研究的方向而產生動力繼續深入研究。謝謝老師在我研究中無頭緒時候，提點出問題所在且給予我許多創意想法，讓我深刻了解自己還有很多不足的地方，需要更精進地學習。感謝葉耀明老師、林均翰老師、陳永昇老師以及許榮隆老師，能夠於當天百忙抽空前來擔任口試委員，每位老師在報告中所提出的問題及建議，讓我在論文中發現缺陷而進行修正，讓論文的內容更加完整。感謝家人提供給我學習上的支援，讓居住在台南的我前來台北就讀學習，其中包括房租、生活開銷以及精神上的鼓勵。大學原本念資管系提升至研究所念資工系，在課堂中可以接觸到工程方面的知識，雖然在學習上很吃力，但是老師們的熱心教導讓我可以慢慢地進入狀況，透過在學校研究時所漸漸地產生興趣，也會開始撰寫自己程式，研發出不一樣有趣的應用，也謝謝曾經幫助過我的同學，在研究所中透過健身、聚會以及共同熬夜學習增加彼此友誼，讓我可以順遂地完成研究的成果，希望各位同學未來的路上可以順順利利，感謝兩年間的陪伴可以度過美好的時光。 iii.

(5) 目錄附表目錄....................................................................................................................... vi 附圖目錄....................................................................................................................... vi 第一章續論.................................................................................................................. 1 1.1 研究背景.......................................................................................................... 1 1.2 研究動機與目的.............................................................................................. 4 第二章文獻探討.......................................................................................................... 6 2.1 情境感知(Context Awareness) ........................................................................ 6 2.2 開放資料(Open Data) ...................................................................................... 8 2.3 政府開放資料(Open Government Data) ....................................................... 10 2.4 鏈結開放資料(Linked Open Data) ............................................................... 11 2.5 資源描述框架(Resource Description Framework) ....................................... 13 2.6 SPARQL......................................................................................................... 15 2.7 Jena API ......................................................................................................... 16 2.8 Google API..................................................................................................... 17 2.9 PHPMyAdmin................................................................................................ 18 第三章系統規劃........................................................................................................ 19 3.1 系統整體規劃................................................................................................ 19 3.2 鏈結資料圖(Linked Data Diagram) .............................................................. 21 3.3 情境感知(Context Awareness) ...................................................................... 27 3.4 縮減範圍搜尋(Reduce Size) ......................................................................... 28 3.5 微笑單車數據分析與推薦............................................................................ 30 3.6 捷運不同格式整合運用................................................................................ 33 3.7 捷運列車到站時間分析................................................................................ 35 3.8 臺北一日遊規劃行程之情境應用................................................................ 36 3.9 使用案例(Use Case Diagram) ....................................................................... 48 3.10 活動圖(Activity Diagram) ......................................................................... 51 3.10.1 瀏覽所有微笑單車資訊................................................................... 51 3.10.2 瀏覽合適微笑停車場資訊............................................................... 52 3.10.3 瀏覽常用微笑單車站點................................................................... 53 3.10.4 使用者新增常用微笑單車站點....................................................... 54 3.10.5 使用者刪除常用微笑單車站點....................................................... 55 3.10.6 瀏覽所有捷運行駛列車資訊........................................................... 56 3.10.7 瀏覽最近捷運站點資訊................................................................... 57 3.10.8 查詢捷運行駛列車到站時間資訊................................................... 58 3.10.9 查詢捷運站點票價以及無障礙電梯資訊....................................... 59 3.10.10 臺北一日遊規劃行程之情境應用................................................. 60 iv.

(6) 3.10.11 分析所處停車場周圍微笑單車或捷運站點 ................................. 61 3.10.12 瀏覽分析及推薦資料..................................................................... 63 3.10.13 縮減搜尋範圍(Reduce Size) .......................................................... 64 3.10.14 動態更新政府開放資料................................................................. 66 3.10.15 使用狀況分析................................................................................. 67 第四章系統開發與實作............................................................................................ 68 4.1 系統架構........................................................................................................ 68 4.2 類別圖(Class Diagram) ................................................................................. 71 4.3 循序圖(Sequence Diagram)........................................................................... 74 4.3.1 瀏覽所有微笑單車站點資訊............................................................. 74 4.3.2 瀏覽合適微笑單車站點資訊............................................................. 75 4.3.3 瀏覽常用站點並查看......................................................................... 76 4.3.4 新增常用微笑單車站點..................................................................... 78 4.3.5 刪除常用微笑單車站點..................................................................... 79 4.3.6 瀏覽所有捷運行駛列車資訊............................................................. 80 4.3.7 瀏覽最近捷運站點資訊..................................................................... 81 4.3.8 查詢捷運列車到站時間資訊............................................................. 82 4.3.9 查詢捷運站點票價以及無障礙電梯資訊......................................... 83 4.3.10 臺北一日遊規劃行程之情境應用................................................... 84 4.3.11 停車場至微笑單車或捷運跨資料集應用 ....................................... 85 4.3.12 縮減範圍搜尋(Reduce Size) ............................................................ 87 4.4 實作畫面........................................................................................................ 89 4.4.1 瀏覽所有微笑單車站點..................................................................... 89 4.4.2 瀏覽合適微笑單車站點..................................................................... 91 4.4.3 瀏覽、新增、刪除常用站點............................................................. 92 4.4.4 分析所在停車場並透過停車場尋找周圍微笑單車或捷運站點(跨資料集應用)................................................................................................ 94 4.4.5 瀏覽所有捷運行駛列車資訊............................................................. 95 4.4.6 瀏覽最近捷運站點資訊..................................................................... 96 4.4.7 查詢捷運列車到站時間..................................................................... 97 4.4.8 查詢捷運站點票價、無障礙電梯以及轉車資訊............................. 99 4.4.9 臺北一日遊規劃行程之情境應用................................................... 101 第五章結論與未來發展.......................................................................................... 103 5.1 結論.............................................................................................................. 103 5.2 未來發展...................................................................................................... 105 參考文獻.................................................................................................................... 106. v.

(7) 附表目錄表 3-1 Data Schema - info ........................................................................... 24 表 3-2 Data Schema - location ..................................................................... 24 表 3-3 Data Schema - time........................................................................... 24 表 3-4 Data Schema - parking garage .......................................................... 24 表 3-5 Data Schema - ubike station ............................................................. 25 表 3-6 Data Schema - mrt ............................................................................ 25 表 3-7 Data Schema - 停車場資訊 ............................................................. 25 表 3-8 Data Schema - 停車場動態格位資訊 ............................................. 25 表 3-9 Data Schema - 微笑單車資訊 ......................................................... 26 表 3-10 Data Schema - 常用微笑單車站點 ............................................... 26 表 3-11 Data Schema - 捷運站點 ............................................................... 26 表 3-12 使用 Reduce Size 的執行時間差異(第一次執行)........................ 29 表 3-13 使用 Reduce Size 的執行時間差異(第二次執行)........................ 29 表 3-14 使用 Reduce Size 的執行時間差異(第三次執行)........................ 29 表 3-15 使用 Reduce Size 的執行時間差異(第四次執行)........................ 29 表 3-16 使用 Reduce Size 的執行時間差異(第五次執行)........................ 29 表 3-17 上禮拜前 3 個小時之微笑單車的使用率以及可用率 ................ 31 表 3-18 上禮拜後 3 個小時之微笑單車的使用率以及可用率 ................ 31 表 3-19 目前時間前 3 個小時之微笑單車使用率以及可用率 ................ 31. 附圖目錄圖 1-1 鏈結資料圖(Linked Data Diagram) ................................................... 3 圖 1-2 開放資料類別個數 ............................................................................ 4 圖 1-3 個別交通工具 App ............................................................................ 5 圖 2-1 情境感知服務流程 ............................................................................ 7 圖 2-2 Linked Open Data 鑑定之標準，5 個 Level................................... 13 圖 2-3 RDF 範例一 ..................................................................................... 14 圖 2-4 RDF 範例二 ..................................................................................... 15 圖 2-5 RDF 關係之概述圖 ......................................................................... 15 圖 2-6 Jena 應用之流程圖 .......................................................................... 16 圖 3-1 系統之互動圖 .................................................................................. 19 圖 3-2 系統之規劃圖 .................................................................................. 19 vi.

(8) 圖 3-3 臺北市政府局部的開放鏈結資料圖 .............................................. 22 圖 3-4 臺北市開放鏈結資料構想圖 .......................................................... 23 圖 3-5 微笑單車時間軸分析 ...................................................................... 32 圖 3-6 捷運不同格式之應用 ...................................................................... 33 圖 3-7 不同格式統一轉換圖 ...................................................................... 34 圖 3-8 不同觀點之情境應用圖 .................................................................. 37 圖 3-9 行事曆記錄圖 .................................................................................. 39 圖 3-10 一日遊交通搭乘圖 ........................................................................ 40 圖 3-11 一日遊規劃行程圖 - 範例一 ....................................................... 41 圖 3-12 交通工具應用顯示圖 - 範例一 ................................................... 42 圖 3-13 搜尋臺北一日遊資訊 .................................................................... 43 圖 3-14 捷運一日遊行程資訊圖 ................................................................ 44 圖 3-15 一日遊規劃行程圖 - 範例二 ....................................................... 46 圖 3-16 交通工具應用顯示圖 - 範例二 ................................................... 47 圖 3-17 使用案例圖 .................................................................................... 48 圖 3-18 活動圖 - 瀏覽所有微笑單車資訊 ............................................... 51 圖 3-19 活動圖 - 瀏覽合適微笑單車資訊 ............................................... 52 圖 3-20 活動圖 - 瀏覽常用微笑單車站點 ............................................... 53 圖 3-21 活動圖 - 使用者新增常用微笑單車站點 ................................... 54 圖 3-22 活動圖 - 使用者刪除常用微笑單車站點 ................................... 55 圖 3-23 活動圖 - 瀏覽所有捷運行駛列車資訊 ....................................... 56 圖 3-24 活動圖 - 瀏覽最近捷運站點資訊 ............................................... 57 圖 3-25 活動圖 - 查詢捷運行駛列車到站時間資訊 ............................... 58 圖 3-26 活動圖 - 查詢捷運站點票價以及無障礙電梯資訊 ................... 59 圖 3-27 活動圖 - 一日遊之規劃行程安排 ............................................... 60 圖 3-28 活動圖 - 分析所處停車場周圍微笑單車或捷運站點 ............... 61 圖 3-29 活動圖 - 瀏覽分析及推薦資料 ................................................... 63 圖 3-30 活動圖 - 縮減搜尋範圍(Reduce Size) ........................................ 64 圖 3-31 活動圖 - 動態更新政府開放資料 ............................................... 66 圖 3-32 活動圖 - 使用狀況分析 ............................................................... 67 圖 4-1 系統架構圖 ...................................................................................... 68 圖 4-2 系統類別圖 ...................................................................................... 71 圖 4-3 循序圖圖 4-4 循序圖圖 4-5 循序圖圖 4-6 循序圖圖 4-7 循序圖圖 4-8 循序圖. -. 瀏覽所有微笑單車站點 ................................................. 74 瀏覽合適微笑單車站點 ................................................. 75 瀏覽常用站點並查看 ..................................................... 76 新增常用站點 ................................................................. 78 刪除常用站點 ................................................................. 79 瀏覽所有捷運行駛列車資訊 ......................................... 80 vii.

(9) 圖 4-9 循序圖 - 瀏覽最近捷運站點資訊 ................................................. 81 圖 4-10 循序圖 - 查詢捷運列車到站時間資訊 ....................................... 82 圖 4-11 循序圖 - 查詢捷運站點票價以及無障礙電梯資訊 ................... 83 圖 4-12 循序圖 - 一日遊之規劃行程安排 ............................................... 84 圖 4-13 循序圖 - 停車場至微笑單車跨資料集應用 ............................... 85 圖 4-14 循序圖 - 縮減範圍搜尋(Reduce Size) ........................................ 87 圖 4-15 瀏覽所有微笑單車以及查看站點資訊 ........................................ 89 圖 4-16 微笑單車站點之 Google Map 導航和使用狀況與推薦 .............. 90 圖 4-17 自訂搜尋範圍頁面以及輸入需求範圍後的搜尋結果 ................ 91 圖 4-18 瀏覽常用站點以及新增常用站點 ................................................ 92 圖 4-19 刪除常用站點(台北市信義區松壽路 11 號) ................................ 93 圖 4-20 瀏覽常用微笑單車站點資訊(台北市中正區汀洲路三段 203 巷 25 號) ................................................................................................... 93 圖 4-21 停車場至微笑單車或捷運跨資料集之應用 ................................ 94 圖 4-22 瀏覽所有捷運行駛列車和更新資訊 ............................................ 95 圖 4-23 瀏覽最近捷運站點和 Google Map 導航 ...................................... 96 圖 4-24 查詢捷運列車到站時間(相同路線).............................................. 97 圖 4-25 查詢捷運列車到站時間(不同路線).............................................. 98 圖 4-26 查詢捷運票價以及無障礙電梯資訊 ............................................ 99 圖 4-27 查詢捷運轉車以及 Google 導航站點資訊 ................................ 100 圖 4-28 查詢所有停車場、Ubike 以及捷運資訊以及輸入行程 ........... 101 圖 4-29 規劃行程顯示圖以及檢視視覺化地圖 ...................................... 102. viii.

(10) 第一章續論 1.1 研究背景現今智慧型手機已越來越普及，而根據統計[1] ，從 2013 年開始台灣的智慧型手機普及率已高達 51%，台灣民眾若出門必定攜帶智慧型手機已高達 81%，也就是說幾乎每兩人之中就有一位隨身攜帶智慧型手機。智慧型手機對於人類來說越來越貼近生活，顯現人們漸漸離不開沒有智慧型手機的生活，大多數人們所從事的休閒、娛樂、通訊、搜尋….等大部分活動都藉由智慧型手機，甚至有不少人感覺：『寧可沒有電視，但是一定要有支智慧型手機』，凸顯某方面智慧型手機漸漸取代電視，伴隨著智慧型手機功能方面日益壯大，除了手機基本的通訊功能之外，也包含 GPS 定位、上網瀏覽、以及各式各樣的感測器應用….等等，智慧情手機所提供加值服務越來越多元化。以上敘述智慧型手機的優點具備有：1.貼近民眾的生活、2.強大且方便的加值服務、3 各種感測晶片集於一身，綜合這三大特點使得智慧型手機亦成為情境感知(稱 Context Awareness)系統的重要發展平台。最近幾年各國政府陸續推廣政府開放資料(稱 Open Government Data)，期許將政府資料公開化，讓一般民眾能自由取用且善加運用，讓資料能有更好的價值。台灣現今已有不少的政府單位率續類似開放資料的平台，讓一般民眾可以利用簡單的搜尋方式找到資料。在 2011 年九月時，臺北市政府開放平台(稱 1.

(11) Data.Taipei)是第一個上線提供給大眾做使用的平台[2]。緊接著政府資料開放平台也伴隨著上線[3]，到至今全台灣大多縣市也隨之有開放平台[15] 。隨著時代演進，開放資料亦日益壯大，許多以開放資料為基礎的加值服務推陳出新，成長般的速度已超乎想像。當網際網路迅速地發達，各式各樣種類資料遍散佈於每個小角落，但是大多數遍散佈於網際網路的資料皆以超文本(Hypertext)方式做呈現，故資料彼此間關係相較薄弱，而且不具備機器可讀性(Machine-readable)，其衍生出整合與分析上的窘境，除此之外超文本是將網頁超連結的方式互相鏈結，而不是利用資料本身來相互鏈結。在資料過度飽和的時代，於是越來越多人強調資料本身潛在力做為相關應用，期望資料能夠通用且機器可讀性的格式來儲存，並且利用資料相關特性可以相互做鏈結，在此造就出 Linked Data 所誕生的意義。 Linked Data 是把 W3C 制定協定作為基礎給予描述資料的方式，然而藉由公開自己的資料與其他開放資料做成鏈結，將資料群集越來越壯大，重要的是資料蘊含著無限潛在力，其便利性也更加強大。以圖 1-1 為鏈結資料圖，而圖中包含有一個資料集為『DBpedia』[17]，在 2007 年是由 OpenLink Software、Freie Universitat Berlin 以及 University Of Leipzig 共同發表出 DBpedia 資料集，而 Wikipedia 是具有結構的資料組合而成，其中皆有一個 Info Block，接著 DBpedia 擷取自於 Wikipedia 的 Info Block，針對每筆不同資料做描述且加以鏈結，造就出 Linked Data。DBpedia 是 2.

(12) 目前廣為人知的 Linked Data，最近幾年啟發許多人響應，至今已高達 50 個以上的資料集與 DBpedia 彼此鏈結，讓 Linked Data 迅速擴張。. 圖 1-1 鏈結資料圖(Linked Data Diagram). 3.

(13) 1.2 研究動機與目的近幾年政府開放資料風靡各國，連帶著網頁應用以及手機應用程式的興起。現今臺北市政府開放資料平台已高達 1828 種資料來源，其中大部分與民眾息息相關的交通資訊以及公共訊息，如圖 1-2。因此臺北市政府希望能響應開放資料的使用，每年舉辦數場次的資訊創意競賽，為了吸引開發者透過臺北市政府開放資料平台的眾多資料集來開發出各種加值服務與應用。臺北市政府也依照本身的開放資料自行研發行動 App，現今已在 Android Store 和 Google Play 中上架，再加上額外有業餘開發的 App，產品多樣到不計其數。目前雖有許多已政府開放資料為基礎的加值服務與應用，但絕大多數僅將政府給予的資料做統整，提供給一般民眾方便查詢、瀏覽的使用，缺乏針對這些資料實質意義的分析應用，讓人有遺珠之憾的感覺，為了將這些資料能貼近人們，而手機本身能夠掌握使用者所處的時間、地點、甚至狀態資訊，結合其他加值服務，我們還能了解使用者對於未來行程規劃、對事物的特殊喜好，能進行與 Open Government Data 做結合分析與應用，能給予更貼近使用者的生活資料，而不是僅能被動的查詢。. 圖 1-2 開放資料類別個數 4.

(14) 然而臺北市政府開放資料所提供的資料，在網路上下載的資料都屬於即時資料，而無法利用先前資料做查詢的應用，於是透過歷史的資料紀錄來建立出分析應用機制，讓資料更具有價值。另外市面上在行動裝置商店所下載交通工具的 App 皆僅做單一的應用服務，如圖 1-3，無法針對旅遊方面讓民眾透過一個系統完整搭配使用，於是構想出交通工具整合為一，建立一日遊行程規劃的應用服務，透過旅遊景點進行搭配呈現，可以讓民眾更清楚地了解一系列旅遊的流程。. 圖 1-3 個別交通工具 App 研究中主要目的是期望能將混亂無章的 Open Government Data 利用 RDF(全名 Resource Framework，稱資源描述框架)的正規化格式進行資料統一格式，將透過使用者不同需求進一步分類，除了能提高搜尋速度的目的，另外結合情境感知(Context Awareness)應用，達到有效使用政府開放資料的意義，同時亦期望透過應用更貼近使用者的生活。上述實作交通方面的應用，例如：停車場、 Ubike 以及 MRT，透過彼此不同資料集進行鏈結的動作，預期能進行不同交通工具的開放資料轉換搭乘租借互相搭配使用，加入行程的規劃能讓原本無相關聯的資料變得更加具有彈性，也能對於旅遊族或上班族更便利的生活。. 5.

(15) 第二章文獻探討 2.1 情境感知(Context Awareness) 利用行動裝置偵測、整合使用者目前的狀態資訊及位置資訊，並且使用所得到的資訊加以分析整合，自動地提供符合使用者需求的資訊和服務。系統會整理出使用者所需要的資訊或是針對目前使用者所處情境狀態給予資訊和服務，透過分析資訊和服務可以減少冗長、不必要的資訊，讓使用者更貼近生活與實際操作應用。最早提出情境感知的概念是在 1994 年 Schilit[24]與 Theimer[25]所提出，主要的概念是將使用者所需要可以善加利用的資訊，依據使用者的情境以及地位置，利用無線傳輸的技術傳遞至使用者。透過感測器偵測使用者的環境狀況，分析判斷服務出最適合的資訊提供給使用者，提升資訊上的效率和服務的舒適度。「情境(context)」是描述使用者在周遭環境中任何非實體或實體的資訊、狀態，非實體包括光亮、時間、風力、時間、經緯度等等，實體則包括人、建築物、地理位置、交通工具、其他物件等等。總而言之，簡單來說情境感知就是和使用者彼此互動所提供的資訊的東西皆可列入參考依據，透過互動所提供的資訊內容皆可以當作「情境資訊」。情境感知的服務流程有四個步驟:1.確認情境資訊、2.感測器感知、3.情境資訊處理、4.提供服務[6]如圖 2-1： 6.

(16) 圖 2-1 情境感知服務流程. . 情境感知資訊：年齡、性別、情緒、習慣、喜好、能力等資訊，以及時間、位置、光亮、氣溫、所處環境設施等等的環境資訊。. . 感測器：行動裝置上軟硬體的使用以及傳感器所得到的資訊，例如陀螺儀、GPS、時鐘、臉部辨識、使用者喜好紀錄等等。. . 資訊處理：可分為兩種處理模式，(1)集中式：將行動裝置感測到的情境資訊．利用無線網路傳輸的技術傳送伺服器端，在從伺服器端運算的結果，最後將使用者設定條件或是情境所計算的結果傳送至使用者的行動裝置。 (2)分散式：在使用者的行動裝置上處理情境資訊的處理加工，並直接得出所需要的結果，提供服務。. . 服務模式：David Kotz 的定義可分為主動服務模式(Active context)以及被動服務模式(Passive context)。所謂主動服務模式為系統依照接收到的情境感 7.

(17) 知資訊，來改變系統的行為模式 (例如：在重要會議時，手機會依據預先輸入在行事曆上會議的時間，會將鈴聲切換到靜音或者拒接)；而被動服務模式指的是依照接收情境的資訊，改變系統的資訊所呈現的方式(例如：當我們買票時，系統會依據使用者曾經的喜好，在購票的時候，會推薦相關的電影)。依據情境資訊的內容，可以將資訊分為五種： I. II.. 時間資訊：季節、白天夜晚、年、月、日等。空間資訊：地理位置、速度、室內室外、海拔等。. III. 環境資訊：交通、氣溫、濕度等。 IV. 社會資訊：相關聯絡人資訊、個人身分等。 V. 設備資訊：停車場格位數、無線上網設備、公車到站狀態等。. 2.2 開放資料(Open Data) 指的是經過處理篩選過的資料集，現今 Open Data 檔案格式種類眾多，包含 JSON、CSV、excel、等等眾多複雜的檔案格式。在紛亂的格式中進行篩選的資料中不受任何專利權、著作權或任何管理機構的限制，任何人皆可自由地使用它，且可利用眾多資料進行開發新的服務功能以及加值服務等。因網際網路迅速火熱的發展，Web2.0 興起，慢慢出現各式各樣的「開放運動」在社會上，例如開放原始碼(Open Source)以及技術開放等等，各種領域伴隨著這股熱潮引起新興運動。目前網路上漸漸出現分享各種開放原始碼平台、Linux 的開放技術也漸漸受到矚目以及硬體界也正盛行 3D 列印等等，皆是開放運動所帶來的影響成果。 8.

(18) 「內容開放」是目前大家所關注的議題之一，主要是開放各種專業領域所能夠清楚地掌握的資料內容，能夠增加各領域之間的技術交流，Science Common 的前執行長 John Wilbanks 曾提過:「曾經許多科學家表示，在這歷史的一刻，正當我們有足夠的技術與能力將科學資料以全球性的層次來進行發佈，增強彼此之間的合作關係且加速新科技的發展，但是很諷刺地看到我們急著把資訊封閉，並嚴格地禁止在這些知識數據上使用新的技術[13]」。有些人認為大多數資料皆是由於大眾所提供出來的資訊，但是大部分的使用者卻無法獲知這些資訊，故藉由內容開放的方式，將資料開放給大眾提供參考使用。綜合以上開放資料的運動逐漸興起，讓政府、學界都有 Open data 運動可以善加使用。依據 W3C eGov Interest Group[26]所提出的定義，開放資料(Open Data)須符合以下兩項標準： . 格式未加工(Raw Format)：不能對資料本身做額外的加工。. . 機器可讀(Machine-readable)：將資訊的格式建構出可讓電腦或者程式進行讀取且加以處理。. 9.

(19) 2.3 政府開放資料(Open Government Data) 顧名思義，是由政府所屬的機關管理，政府平台所提供各式各樣的類型開放資料，其內容大多數皆在政府施政時匯集於一般民眾使用，不僅可提供使用者去讀取，政府施政透明也是其中大宗旨之一，在世界各國政府正推動的趨勢，經由政府資料的開放化，而促使了跨機關相互的資料可彼此間順利地交流，更能讓廣大民眾的滿足需求，且可增強監督政府的方式。伴隨著智慧型手機普遍的時代，各種應用服務持續推出，政府開放資料也搭上這股順風車，利用有限的資料來源，善用民間的無限想像力，進一步開發出能讓人們能更舒適更貼近的服務應用，來達到政府、業者、民間三者可全贏的局面。依照行政院院會決議第 3322 次指示[4]，Open data 能增加政府施政透明度、提升民眾的生活品質，且滿足業界所需，對於政府各個層級或者各個部會之間決策的品質都扮演其中的重要決策數據，可想而知開放資料的重要性，各個部門皆應該把重點放在民眾的需求考量為第一優先，在規劃時也需考慮到機器的可讀性。開放資料的類型應優先考量於提升民眾生活品質，如食、衣、住、行、文化、就業、育樂等都是頗為重要的各項生活層面，期許往後透過政府開放資料，進一步促成各個政府機關以及民間彼此發展出多樣的應用與服務，造就出更加完美的生活品質。依照 W3C eGov Interest Group[27]定義，政府開放資料須以下八條原則為標準： 1.. Complete：所有的開放資料皆可被任何取用，不能加設密碼或者權限。 10.

(20) 2.. Primary：所有的資料需未經修改、整合過的，皆為最原始的。. 3.. Accessible：資料能被任何人所使用，且能做為任何應用。. 4.. Timely：資料須是最即時的，不可是過時的資料。. 5.. Machine processable：資料是可被電腦、程式可讀的格式做為儲存，讓資料得以被自動地存取。. 6.. Non-discriminatory：資料能被任何取用，不會受限於權限之影響。. 7.. Non-proprietary：能重複使用的存取資料，不影響互斥的存取。. 8.. License-free：資料沒有明確版權或是法規之限制。但是若部分有合理機密的資料、特別權限之限制或是隱私，則允許能有部分之版權限制。. 2.4 鏈結開放資料(Linked Open Data) 鏈結資料(Linked Data)是透過資料之間的關係做成鏈結的一種方法，利用鏈結後所產生的資料會具有結構性。而且是藉由資料彼此之間的鏈結，資料與資料間能夠互相溝通，如此就能提升出資料的價值與用途。鏈結資料(Linked Data)是建構於標準網路的技術之下，例如 RDF、HTTP、URIs 等等，其中用途是在於透過資料結構化的雜亂資料，能讓資料更具有機器可讀且有結構化的性質，更進階地能夠使用電腦進一步做規模化或者自動化邏輯的分析，將資料的數據能完整的發揮出應有的價值。 Tim Berners-Lee 在 2009 年所提出了四項核心標準[19]： 1. 使用 URI 描述出事物或者資源 11.

(21) 2. 使用 HTTP URIs 提供所有的資源藉由網際網路能讓使用者去存取且使用 3. 對於各種 URI 的資源提供有用且正確的資訊，進一步使用 SPARQL 和 RDF 去做查詢以及描述 4. 提供鏈結到有關其他事物的 URI Linked Open Data 基礎建構於 Linked Data 的方法，希望由政府或各種企業所能提供的多項開放資料，進一步鏈結資料的利用方式，能提供給一般民眾做使用，透過 Linked Data 的易分享性、易可讀性，增強開放資料所能帶來的好處。 Tim Berners-Lee 在 2010 所提供出一套能針對 Linked Open Data 的鑑定標準 [20]。根據圖 2-2 中所鑑定之標準，其中共有 5 個 Level，若 Level 越高所表示的是資料越貼近地符合 Linked Open Data 的精神。 Level 1. 無論資料格式，利用開放授權的此種方法開放(在此同時只能稱為 Open Data)。 Level 2. 全部資料皆以機器可讀取性且能結構化的格式發表，(例如當使用 Excel 來紀錄數據並取代紙本的掃描圖片檔。 Level 3. 符合 Level 2，進一步利用非授權資料的格式，例如 JSON 、 CSV…等等來取代 Excel。 Level 4. 符合上述全部的規範，且利用 W3C 定義出開放資料之標準格式 (例如 SPARQL 、RDF)來描述的資料。 12.

(22) Level 5. 符合上述全部的規範，所提供的資料能讓資料連結至其他人，目的是將資料之間彼此鏈結。. 圖 2-2 Linked Open Data 鑑定之標準，5 個 Level. 2.5 資源描述框架(Resource Description Framework) 資源描述框架(Resource Description Framework，簡稱 RDF)以及 RDF Schema 是全球網際網路資訊協會(簡稱 W3C)所提出問題中的先導規範，目的是解決資源描述之問題，描述的豐富性及詳細表達出網路資源的結構與內容 [17]。在 2004 年 2 月，RDF 已成為 W3C 標準，並允許讓使用者或者開發者能建立階層式的屬性和概念，讓資料呈現出本體(Ontology)的樣貌、雛型，主要為用來可供閱讀再使用、資料交換、網路編碼和機器可解析且可讀的 metadata，提供架構的基礎。 RDF 主要用處是使用所呈現出網路資源的狀態與資訊，適合使用在用來表示詮釋得資料，且載明出特定領域之框架(Schema)，方便於資源描述語彙中做 13.

(23) 宣告該領域，利用框架中所能表達領域的概念、定義以及階層架構彼此之間的關係，能將從語法的某層級提升至讓該領域的應用中語意的層級，能將機器去理解與處理，而且不會容易喪失原本語意中的通用架構[5]。 RDF 用來建構在 XML 之上，基本的模型包含 Statement、Resource 和 Properties。Resource 有兩種能呈現的型態：「Literal Resource」和「URI Resource」。例如圖 2-3，存在於一個是以 URI 來描述的 Resource：長框中右方的『tshirt』；另外有兩種 Properties，分別：『size』和『color』；『size』的 Value 為上述所說的 Literal Resource：『12』；接著是『color』的 Value 則是為上述所說的 URI Resource：『white』。. 圖 2-3 RDF 範例一 RDF 所能描述物件中基本單位的是 Statement。Statement 是用來描述事情或者事物，其所使用到的三體(triple)，分別代表的是： Object、Subject 以及 Predicate(Property)。這三種所能描述出一句話：「Subject has a Predicate, which is Object」，於圖片 2-4 為例。 14.

(24) 圖 2-4 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』、也有一個屬性為『color』，其中的值為『白色』，若用圖來表示如圖 2-5。. 圖 2-5 RDF 關係之概述圖. 2.6 SPARQL SPARQL 是 SPARQL Protocol and RDF Query Language 縮寫而成，目的是用在 RDF 內相關的 Resource 查詢語言。RDF 的查詢語言延伸而來就叫做 SPARQL，例如 SeRQL、RDQL、rdfDB、發展而產生出來，用於提供人們進一步語意網相關的研究與開發。SPARQL 在 2008 年已經成功成為 W3C 推薦的標準。 15.

(25) 2.7 Jena API 伴隨著各種領域的資料量大幅地驚人成長，出現各種不同的檔案型態，由於檔案彼此之間互相獨立，這就是造成了檔案的數據相當地龐大，但是卻無法適時且有效利用的窘境。為了處理這類狀況，我們必須針對這類複雜的數據建構出正規化的格式，不但能讓機器可讀，而且可以為了應用程式開發者創造出合適的開發環境，激發出無限的創造力。Jena API 是 HP Labs 利用 Java API 所研發出來的，目的是提供將資料透過本體轉換出的應用程式介面，此用於 OWL 和 RDF 所組合而成的本體(Ontology)，所能提供一系列的查詢、創建、鏈結以及修改的動作。原本混亂的資料在本來中並沒有提供查找、搜尋的功能，另外讓資料轉換出本體完整描述後能使用 SPARQL，代表「 SPARQL Protocol and RDF Query Language」( SPARQL 協定和 RDF 查詢的語. 言)能針對指定的資料迅速地完成搜尋。於 2008 年，SPARQL 已正式成為一項 W3C 推薦標準。下圖 2-6 表示 OWL 、Jena API、RDF 以及 SPARQL 彼此之間的關係[11]。. 圖 2-6 Jena 應用之流程圖 16.

(26) 根據圖片 2-6 所分別於下列五種步驟： 1.. 首先使用 Jena API. 2.. OWL 尋找出合適的 RDF 檔案或者符合的條件. 3.. RDF 會根據 OWL 所規定的規則. 4.. 接續上述第三個步驟能產生 Ontology. 5.. SPARQL 搜尋的語法去 Ontology 中查詢，且拿取需要的資料. 2.8 Google API Google API 是頗盛名的谷歌公司研發出個應用程式介面。其中網際網路的應用軟體具有優良的開放性，為了滿足一般使用者的需求，所提供出豐富且多樣的產品與服務；在此同時也為滿足開發者來開發應用程式，谷歌公司則提供能大量並且能協助廠商來開發出整合的 API 介面[21]。現今谷歌公司在市面上已開放出 60 種以上的 API，功能範圍非常廣大，每種谷歌都能提供具備可以利用對應的 API 進行呼叫的服務。然而 Google API 時常會與 JSON、XML 或者 JavaScript 等等做結合的應用技術。目的是為了能讓許多人能夠使用谷歌的服務創造新奇的應用，谷歌也提供眾多不需要編寫程式，就單單需要利用簡單的設定可以自然地使用 API 的工具。. 17.

(27) 2.9 PHPMyAdmin PHPMyAdmin 是個以 PHP 作為基礎，利用 Web-Base 一種方式架設在網路主機上 MYSQL 的資料庫做為管理工具，管理者必須利用 Web 上介面管理 MySQL 的資料庫。PHPMyAdmin 的一個大優勢是它與其他 PHP 的程式都需在網頁伺服器中來進行執行，但是我們能在無論任何地方利用程式所產生出 HTML 的介面進一步地去遠端，且針對資料庫中進行自由地新增、刪除…之類的動作[22]。其中主要包括的功能如以下： . 建立、刪除、修改以及查詢資料庫。. . 可依據使用者的需求進行多國語言的使用者介面切換。. . 可將資料表中複雜的資料任意地匯入或匯出製成各種的格式檔案。. . 資料表的維護方面，基礎的功能如以下六種： 1.. 資料表的檢查. 2.. 資料表的修復. 3.. 資料表的分析. 4.. 資料表的最佳化. 5.. 資料表的強迫更新. 6.. 建立和檢視出 View 之功能. 18.

(28) 第三章系統規劃 3.1 系統整體規劃. 圖 3-1 系統之互動圖. 系統互動中主要的對象區分為三種：有使用者(Client)、伺服器(Server)以及政府開放資料網站(Open Government Data)。政府開放資料網站所提供系統需求的開放資料作為使用，而伺服器是進行一系列將資料做處理，利用使用者端所提供的情境資訊或不同條件與使用者進一步互動。. 圖 3-2 系統之規劃圖 19.

(29) 研究中主要區分為三個部分，第一部分為從臺北市政府公開資料物抓取需要的資料，將不同資料格式一律轉成 JSON 格式，再進行轉換為 RDF 格式來描述，也進行給予能存取的平台；第二部分為臺北市政府目前僅給予當下時間的資料，故不能給予民眾進行查詢歷史紀錄的資料，因此研究中不僅會將資料轉換為 RDF 格式，也同時地將每筆所更新的資料存取至資料庫中，根據使用者需求，進行分析資料且將回傳結果顯示於使用者介面上；第三部分為使用者端，當使用者利用應用程式，將根據目前的時間情境感知資訊(稱 Time Based Context Information) 和所處的地理環境情境感知資訊(稱 Location Base Context Information)進行條件分析，而從 Server 端獲得相對應的資料。臺北市政府目前提供的資料格式混雜，可讀性差，無法輕易存取利用，因此於研究建立一個 RDF Interface，將臺北市政府提供的資料一律轉換為 RDF 資料格式所儲存，並利用使用者需求，讓各式各樣的資料集做整合，建立出 Linked Open Data 來達成統一格式的目的。在統一格時候，可讀性相對較佳、資料也能輕易地建立鏈結，而藉由將資料彼此之間的鏈結，不同類型的資料能輕易找出鏈結，以利進一步作資料分析且運用。RDF Interface 將提供 SPARQL 的端點，以便讓使用者能利用 SPARQL 做查詢、善加利用這些資料，開發許多加值的應用服務。於研究會談及相關技術和開發利用 Context Aware 應用服務做結合。研究中將結合『停車場資訊(Park)』、『微笑單車資訊(Ubike)』以及『捷運 20.

(30) 資訊 (MRT)』三份不同資料，讓使用者能瀏覽臺北市所有停車場、微笑單車以及捷運的相關即時資訊，而針對捷運到站時間以及車輛空位個數會隨著時間不同給予使用者即時到站時間以及空位個數。於服務中加入情境感知(稱 Context Awareness)的概念，根據使用者的情境給予符合需求的停車場、微笑單車或捷運資訊，讓服務更加貼近使用者生活，本研究所利用到的情境感知主要有 Time-Based 與 Location-Based 兩種模式做為提供服務應用。. 3.2 鏈結資料圖(Linked Data Diagram) 臺北市政府現今已經提供很多種開放資料來提供民眾使用，但是由於格式相當地雜亂，使得開發者或者一般使用者困難地做應用，必須先得透過處理加以分析，再經過整理之後才可以自由地進行開發或者運用服務。研究中目的是要解決資料格式雜亂的窘境，於研究所採用的方法為：利用 RDF 來儲存格式，取而代之先前雜亂的資料格式，加強資料能可讀性，於進一步透過整理之後的資料來建立鏈結資料(Linked Data)，增強資料的擴充以及實用性。本研究中利用 RDF 儲存格式的方式，描述出政府開放資料，且提供存取的平台(例：SPARQL)，方便一般使用者進行存取以及閱讀。臺北市的政府開放資料集現今已經提升到了 1852 筆，相較前幾年的 323 筆，可見每年成長速度相當地迅速，相信未來的一大趨勢是該如何處理相當龐大的數據來善加利用。資料集中與『地理環境』相關約莫有 7 成不同的資料，故在研究中利用地理環境的條件來做研究的核心概念，透過地理環境的條件建構出 Linked Data，嘗試地將符合 21.

(31) 以相關條件的不同資料來彼此之間鏈結在一起，建立鏈結資料且進行創新的應用。以下是擷取臺北市政府局部的開放資料所繪製的鏈結圖，如圖 3-3。. 圖 3-3 臺北市政府局部的開放鏈結資料圖以上的 Open Data Diagram 總共八個資料來源(圖中藍色圈)，其中包括臺北市停車場(Parking Garage)、臺北市社區活動中心(Community)、臺北市案件統計 (Law Case Record)、臺北市人口資訊(Population Info)、臺北市警察局(Police Station)、圖書館資訊(Library)、臺北市消防局(Fire Department)、臺北市急救責任醫院(Emergency)，以上只是局部的部分。研究中打算會利用到三種不同資料的來源且建立 RDF Interface，其中分別：臺北市停車場資訊(於台北市停車管理工程處所提供，屬於交通運輸類別)、臺北市微笑單車資訊(於台北市交通局所提供，屬於交通運輸類別)、臺北市捷運資訊(於台北市公共運輸處提供，屬於交通運輸類別)，三種不同資料來 22.

(32) 源類別皆為交通運輸類，建構出 Linked Open Data Diagram，如圖 3-4。. 圖 3-4 臺北市開放鏈結資料構想圖. 圖 3-4 中有三個不同主體： 1.. Ubike Station(微笑單車站點資訊). 2.. Parking Garage(停車場資訊). 3.. MRT(捷運站點資訊). 分別由四個基本單位構成： 1.. Info：使用來記錄基本的資料，例如 Name、Type、ID…等等。. 2.. Location：使用來記錄地理環境資料，例如經緯度、地址…等等。. 3.. Time：使用來記錄營業時間或者服務時間。. 4.. Ticket：使用來記錄車票價錢。. 最後是 Context 用於情境感知的部分，根據使用者的需求，透過地理環境資料 23.

(33) (Location-Based)抓取需要的資料，且將需要的資料進一步鏈結的動作，另外製成一份全新的鏈結資料。以下是實作出各個不同資料集 Dataset 的 Schema 表 3-1 Data Schema - info xmlns:info=”http://data.taipei.gov.tw/infomation#” Attribute. Data Type. info:id. Long. Description 該筆資料唯一的識別碼. info:name. String. 該筆資料名字. info:type. String. 該筆資料不同屬性。其中會利用到三種不同 type，分別是： parking 、ubike 與 mrt. 表 3-2 Data Schema - location xmlns:loc=”http://data.taipei.gov.tw/location#” Attribute. Data Type. Description 地址資訊. loc:address. String. loc:area. String. 區域資訊。其中項目為臺北市全部的行政區域. loc:latitude. Double. 二度分帶的座標(UTM)y 軸座標之資訊. loc:longitude. Double. 二度分帶的座標(UTM)x 軸座標之資訊. loc:original_latitude. Double. 緯度的資訊. loc:original_longitude. Double. 經度的資訊. 表 3-3 Data Schema - time xmlns:time=”http://data.taipei.gov.tw/time#” Attribute. Data Type. time:start. String. Description 服務開始的時間. 服務結束的時間 String 表 3-4 Data Schema - parking garage xmlns:pa=”http://data.taipei.gov.tw/parking#” time:end. Attribute. Data Type. pa:total_car. Integer. Description 停車場的車位總數. pa:available_car. Integer. 停車場剩餘的空位數 24.

(34) 表 3-5 Data Schema - ubike station xmlns:ub=”http://data.taipei.gov.tw/ubike#” Attribute. Data Type. ub:total_ubike. Integer. ub:available_ubike. Integer. Description 微笑單車的總車數微笑單車剩餘的可用車數. 表 3-6 Data Schema - mrt xmlns:mrt=”http://data.taipei.gov.tw/mrt#” Attribute. Data Type. mrt:start_station. String. Description 捷運發車的起點. mrt:end_station. String. 捷運末班的終點. mrt:updatetime. Double. 捷運發車的時間. 以下為本次研究主要的 Data Schema：表 3-7 Data Schema - 停車場資訊停車場資訊 Attribute. Data Type. info:id. Long. Description 該筆停車場的唯一識別. info:name. String. 該筆停車場資料的名字. info:type. String. 該資料的類型：屬性設定為”parking”. loc:longitude. Double. 二度分帶 x 軸座標資訊. loc:latitude. Double. 二度分帶 y 軸座標資訊. loc:address. String. 站點位置的資訊. loc:area. String. 該站所屬區域. pa:total_car. Integer. 該站總車位數量. time:start. String. 該站開始時間. time:end. String. 該站結束時間. 表 3-8 Data Schema - 停車場動態格位資訊停車場動態格位資訊 Attribute. Data Type. info:id. Long. Description 該筆停車場的唯一識別. pa:available_car. Integer. 該筆停車場的動態格位. 25.

(35) 表 3-9 Data Schema - 微笑單車資訊微笑單車(或 Ubike)資訊 Attribute. Data Type. info:id. Integer. Description 微笑單車唯一的識別碼. info:name. String. 微笑單車站點的名稱. info:type. String. 資料的類別：屬性設定成”ubike”. loc: longitude. Double. 二度分帶 x 軸座標資訊. loc: latitude. Double. 二度分帶 y 軸座標資訊. loc:original_latitude. Double. 緯度的資訊. loc:original_longitude. Double. 經度的資訊. loc:address. String. 站點位置的資訊. ub:total_ubike. Integer. 該站微笑單車的總數. ub:available_ubike. Integer. 該站剩餘單車的數量. 表 3-10 Data Schema - 常用微笑單車站點常用微笑單車資訊 Attribute. Data Type. Description 常用微笑單車站點的唯一識別碼. info:id. String. loc:address. String. 常用微笑單車站點的地址. loc:latitude. Double. 緯度的資訊. loc:longitude. Double. 經度的資訊. 表 3-11 Data Schema - 捷運站點常用微笑單車資訊 Attribute. Data Type. info:id. String. Description 捷運的唯一識別碼. loc:name. String. 捷運站點的名稱. loc:type. String. 資料的類別：屬性設定成”mrt”. loc:longitude. Double. 二度分帶 x 軸座標資訊. loc:latitude. Double. 二度分帶 y 軸座標資訊. loc:address. String. 站點位置的資訊. mrt:start_station. String. 該站捷運發車的起點. mrt:end_station. String. 該站捷運末班的終點. mrt:updatetime. Double. 該站捷運發車的時間 26.

(36) 因為政府所提供的開放資料，停車場動態格位與停車場資訊兩種分別有彼此不同 RDF 的 DataSet，但是彼此之間仍然能利用唯一識別的 ID 的資訊進一步做資料的溝通。在實作 Query 時會利用『縮減搜尋範圍(Reduce Size)』的技術來進行，目的是減少不需要的時間以及搜尋。其中微笑單車的部分全部資訊都包括動態車輛皆於同一份的開放資料裡存在。. 3.3 情境感知(Context Awareness) 使用「時間情境感知(稱為 Time-Based)」和「地理環境情境感知(稱為 Location-Based)」來偵測於環境資訊，用這兩種做為基礎，提供出能符合的情境規則資料於使用者做使用。研究中使用到三種資訊，分別為『停車場資訊』、『捷運資訊』以及『微笑單車資訊』開發出情境感知行動應用。利用使用者所使用時的應用程式獲得的時間資訊以及地理環境位置，此獲得的資訊會立即回傳至 Server 端，進一步做資料的整合與分析，產生出一份最清楚且貼近使用者的資料給使用者做參考。在此舉例一個貼近使用者的例子：使用者的位置目前於「台北市文山區汀洲路四段 88 號」，若想要搜尋鄰近的交通工具，在此提供三種可做選擇，分別是停車場資訊、捷運資訊或者微笑單車站點，接著只要觸碰一個按鍵，使用者需要的服務就會立即將鄰近且符合的相關資訊依依呈現於行動裝置的介面上，能提供使用者做不同選擇中的參考，另外使用者也能自由地輸入需要的範圍，利用輸入所需要的範圍再加上目前的地理資訊做結合，系統就會立即提供使用者需要的結果。 27.

(37) 3.4 縮減範圍搜尋(Reduce Size) 本研究中利用三個不同的資料集，分別是：『停車場動態格位資訊(依據時間來動態更新停車格位)』、『停車場資訊(包括時間資訊、地理位置以及收費資訊)』、『微笑單車資訊(動態車輛資訊以及地理位置)』。其中專注於停車場動態格位資訊以及停車場資訊進一步做一連串的處理，當使用者欲用應用程式時，不會因每次針對最大範圍資料來做資料的鏈結動作，同時拿取局部資料做使用，其實是依據先前搜尋產生記錄的資料，接著做詳細的分析，若有偵測到地理情境資訊和使用者自行設定皆符合規則時，此時只需要對先前進行搜尋的局部範圍中得到的結果，進一步做資料的鏈結動作，接著拿取與使用者自行設定的資料來看是否符合，目的是縮小範圍內的分析做處理能有效地減少搜尋或者鏈結資料所花的時間，而且每次使用時所留下的資料，日積月累地數量是相當龐大且可觀，利用這些資料能進行許多的應用與分析，例如：自動化推薦、使用者的習慣…等等。. 28.

(38) 下表比較使用 Reduce Size 以及未使用 Reduce Size 做搜尋之時間差異。表 3-12 使用 Reduce Size 的執行時間差異(第一次執行) First use.定點搜尋周圍 2 公里搜尋花費時間(milliseconds) 使用 Reduce Size 未使用 Reduce Size. 1620 1605. 表 3-13 使用 Reduce Size 的執行時間差異(第二次執行) Second use.定點搜尋周圍 1.5 公里搜尋花費時間(milliseconds) 使用 Reduce Size 未使用 Reduce Size. 1585 1650. 表 3-14 使用 Reduce Size 的執行時間差異(第三次執行) Third use.定點搜尋周圍 1 公里搜尋花費時間(milliseconds) 使用 Reduce Size 未使用 Reduce Size. 1410 1499. 表 3-15 使用 Reduce Size 的執行時間差異(第四次執行) Forth use.定點搜尋周圍 0.5 公里搜尋花費時間(milliseconds) 使用 Reduce Size 未使用 Reduce Size. 1225 1452. 表 3-16 使用 Reduce Size 的執行時間差異(第五次執行) Forth use.定點搜尋周圍 0.3 公里搜尋花費時間(milliseconds) 使用 Reduce Size 未使用 Reduce Size. 1185 1422. 29.

(39) 3.5 微笑單車數據分析與推薦臺北市政府提供微笑單車的資訊，其中包括「動態車輛資訊」以及「地理環境資訊」。「微笑單車的動態車輛資訊」是當中最具有價值的資料，遺珠之憾的是現今卻無法於特定時間點中獲知微笑單車的車輛資訊。舉例來說：若使用者目前剛於公司開完重要會議時，欲搜尋於公司附近且無需等候車位的微笑單車的站點，但此時距離開完會議需一段時間，但不能預先獲知鄰近微笑單車站點的時間點能看出還有多少車輛的機率，若是從已租借到車輛的使用者觀點著手，也不能知道鄰近微笑單車站點此時是否有空位以及該站的成功歸還機率有多少。系統建置出一個從『真實數據』去做分析且預測推薦機制，每隔時間會利用臺北市政府開放資料去做更新，同時存取至資料庫去做分析，來呈現微笑單車可用率以及使用率的模型，能使使用者利用分析的資料獲知微笑單車的前後時間點中使用狀況，以下這四筆公司是計算微笑單車的可用率(剩下車輛的比率)以及使用率(租借的比率)。 Availability Rate = Utility Rate =. Available ubike Total ubike. (Total ubike – Available ubike) Total ubike. Average Availability Rate = Average Utility Rate =. AvailabilityRate1+⋯+AvailabilityRate15 15. UtilityRate1+UtilityRate2+⋯+UtilityRate15 15. 利用前一個禮拜採用的數據分析當時的時間前後三個小時之間以及目前的 30.

(40) 時間前三個小時，來計算微笑單車可用率和使用率，如圖 3-5 之微笑單車時間軸的分析圖將表 3-17、3-18 以及 3-19 做呈現。表 3-17 上禮拜前 3 個小時之微笑單車的使用率以及可用率過去時間為 2016/05/4 13:14:30 10:14. 11:08. 11:38. 12:38. 12:44. 13:08. 使用率. 76%. 70%. 76%. 69.5%. 67%. 65.5%. 可用率. 24%. 30%. 24%. 30.5%. 33%. 34.5%. 表 3-18 上禮拜後 3 個小時之微笑單車的使用率以及可用率過去時間為 2016/05/4 13:14:30 13:38. 14:08. 15:17. 15:47. 16:17. 16:47. 使用率. 65%. 65.5%. 67%. 69%. 68%. 65%. 可用率. 35%. 34.5%. 33%. 31%. 32%. 35%. 表 3-19 目前時間前 3 個小時之微笑單車使用率以及可用率目前時間為 2016/05/11 13:14:30 10:14. 11:08. 11:38. 12:38. 12:44. 13:08. 使用率. 65%. 65%. 66%. 65%. 64.5%. 64%. 可用率. 35%. 35%. 34%. 35%. 35.5%. 36%. 31.

(41) 圖 3-5 微笑單車時間軸分析在圖表中可以觀察發現當下時間之後三個小時微笑單車的使用情況，使用率幾乎皆大於 65%的情況，代表示租借者有一定機率至該站點無法租借微笑單車；相對地可用率幾乎都在 35%以內，代表是正在使用微笑單車的民眾至該站點有較大機率能歸還微笑單車。由真實的數據進一步分析能給予使用者最客觀且符合該站點使用情況的數據，讓使用者能根據數據判斷說是否要前往該微笑單車站點進行租借或歸還的動作，視覺化的圖表也較易讓使用者做參考基準。 32.

(42) 3.6 捷運不同格式整合運用臺北市政府開放資料平台目前有著大量的資料集，在如此龐大資料集中找出有用的資料在加以應用，本研究中在臺北市政府開放資料平台搜尋有關於捷運的資料集，其中找出有四種資料集可以在捷運上做搭配使用，分別是「臺北市捷運系統票價」、「臺北市捷運車站無障礙電梯位置」、「臺北捷運列車到站站名」和「臺北捷運高運量系統及文湖線相鄰兩站之行駛之間、停靠時間」，透過彼此的互相搭配，可以讓捷運功能做的更加完善，也可以透過不同資料來進行串聯使用，來達到想要的結果，但是「臺北市捷運系統票價」、「臺北市捷運車站無障礙電梯位置」、「臺北捷運列車到站站名」和「臺北捷運高運量系統及文湖線相鄰兩站之行駛之間、停靠時間」四種資料中分別都是不同的格式，不同格式對想製作加值的服務會相當的混亂，使得一般使用者或開發者難以應用，必須做善加的處理才可應用，如圖 3-6。. 圖 3-6 捷運不同格式之應用 33.

(43) 由於臺北市政府公開資料有著各式各樣的格式，包含 csv、xls、xml、txt… 等，其格式混雜且多種，讓開發者或ㄧ般民眾難以去做使用，甚至需要的資料為不同檔案類型，本研究為了解決雜亂的格式去做處理，利用捷運的構想運用於臺北市政府公開資料，在捷運眾多資料中採用的四筆資料去做加值服務的應用，恰巧需要的資料皆為不同格式（csv、xls、xlsx 以及 json），於是利用 php 的程式語法來統一格式，讓四筆資料格式中 csv、xls、xlsx 皆一律轉換為 json，並進一步產生 rdf 格式進行之後的應用，目的是解決資源描述，豐富的描述及表達網路資源的詳細內容與結構讓資料具有本體的雛型，讓資料交換、網路編碼、可供閱讀再使用、機器可讀可解析的 metadata，提供基礎的架構，進而讓開發的應用有著更好呈現的效果，創造出更多更有價值的加值服務應用，如圖 3-7。. 圖 3-7 不同格式統一轉換圖 34.

(44) 3.7 捷運列車到站時間分析臺北市政府提供捷運公開資訊，其中包括「臺北捷運列車到站站名」、「臺北捷運高運量系統及文湖線相鄰兩站間之行駛時間、停靠站時間」是其中用來計算捷運到站計算時間的應用，目前臺北市政府所提供的開放資料中沒有明確的給使用者提供預測捷運到站的時間點，只有提供此時目前行駛列車中的時間，故我們利用這兩份政府公開資料來推算說此時位於捷運上的站名，經過計算推得預計多久會到達目前位於此站的時間，方便使用者利用此資訊可以得知捷運列車中何時會到達來把握時間。 ArriveTime : 列車到達此站時間。 UpdateTime : 行駛中列車時間。 EstimateTime：預估多久時間會到達。 NowTime：目前使用者此刻時間。 StopTimeA : A 站停靠時間。 StationA_to_ StationB : A 站到 B 站行駛時間。計算如下： ArriveTime = UpdateTime + StopTimeA + StationA_to_ StationB+….. EstimateTime = ArriveTime – NowTime. 35.

(45) 3.8 臺北一日遊規劃行程之情境應用臺北市是繁榮且便利的都市，在這繁榮的都市中必然有著車流量龐大的問題．因為人口過於稠密，在臺北茫茫人海中，尤其是在上下班時間路上不管機車或者汽車總是水洩不通，於是目前上班族或者學生會選擇大眾交通工具，例如捷運、Ubike、公車…..等等，為了提供更好的生活品質以及解決車位一票難求問題，所以我們營造出一個情境應用，讓使用者可以依據當時的情形並透過 APP 解決到達目的地的過程，其中在路途的過程中可以透過不同交通工具的轉換得知如何搭乘避開尖峰時期所帶來的車潮以及獲知即時的資訊，以便讓使用者大大節省時間且避免白跑一趟之情況。本研究中以臺北市為一日旅遊的規劃行程為模擬，建構出情境應用的例子，首先以兩種例子做為出發點：第一種是以使用者自行安排為觀點，利用使用者自己絞盡腦汁構想的行程進行規劃，安排一套適合全家可以玩樂整天的行程，首先以地點做為優先構想，再來利用交通工具去融入原先規劃的行程，以交通工具做為搭乘方式去各個景點玩樂，接著以 Open Data 的概念利用研究中所開發的功能進一步做結合應用，讓使用者可以馬上獲得即時資訊去進行一天的旅遊；第二種是以部落客熱門文章為觀點，利用網路上熱心民眾分享的文章去做規劃行程的動作，避免行程中出現瑕疵，首先從推薦行程進行規劃的藍圖，再來配合客製化的交通工具搭配出屬於自己的方式，最後結合 Open Data 所開發的功能，利用即時資訊考慮使用者目前需求做為旅遊的主軸，如圖 3-8。 36.

(46) 圖 3-8 不同觀點之情境應用圖 37.

(47) 以使用者自行安排的觀點為例，當一家人出發到台北遊玩時候，假設我們是台北一日遊之行程，因為網際網路的發達，首先我們可以利用各個旅遊景點的官方網站獲得玩樂的情報，其中包括交通資訊以及圖片中有關於行、育、樂方面，方便我們可以對於眾多的旅遊指南來事先做功課，再來先利用手機的行事曆來紀錄行程的安排與時間，假設安排台北一日遊之行程，早上 10 點到下午 3 點到花博公園欣賞不定時的展覽和一起吃頓美味午餐，下午 3 點到下午 5 點到林安泰古厝觀賞古蹟之美，下午 5 點到晚上 8 點在淡水逛著淡水老街買小吃以及著名的淡水阿給，接著最後晚上 8 點到 10 在漁人碼頭走著繽紛的吊橋順便欣賞美麗風景，其中包含交通時間，重要的是需要思考如何搭乘何種交通工具到達遊玩的目的地，緊密的思考可以省下不少時間且更可以愉快的過一天，如圖 3-9。. 38.

(48) 圖 3-9 行事曆記錄圖在此我們在行事曆中的行程加入交通工具來製作圖示．模擬一些行進到達的方式，其中一開始我們有兩種方式，第一種是若我們是以汽車為代步起點出發，我們可以搜尋附近距離花博公園鄰近的停車場來停放汽車，之後以 ubike 方式遊玩花園公園，第二種是若我們是以捷運抵達，以搜尋附近鄰近的捷運站進行搭乘，再到達紅線圓山站即可到達，之後以 ubike 方式遊玩花園公園，臨安泰古厝位於花園公園附近，便可利用 ubike 到達此處，接著搭乘捷運紅線去淡水老街買名產逛街，其中捷運站附近有 ubike 可以租借，騎乘 ubike 逛淡水周圍的河堤，沿路可以欣賞街頭藝人的表演，另外漁人碼頭騎乘 ubike 可從此處到達，晚上欣賞美景吹著海風別有一番風味，如圖 3-10。. 39.

(49) 圖 3-10 一日遊交通搭乘圖當我們都一切想好行程的安排，在 App 畫面中加入規劃行程的功能，可以把事先規劃好的行程安排進去，首先進入選擇交通工具會提供給使用者從臺北市政府公開資料所提供的各項交通工具給使用者選擇，其中包括：停車場、微笑單車以及捷運站點，依據想到達的地點讓使用者自行輸入，每當輸入及選擇完成一筆資料後會立即顯示於畫面中，若輸入多筆資料，顯示會提供地址、地點、搭乘何種交通工具到達目的地等相關資訊，可以更清楚明白行程規劃的流程。另外提供顯示在地圖的畫面，當使用者按檢視地圖的按鈕，會把使用者所選擇的交通工具完全呈現且依據優先選擇來畫線，讓使用者能更直覺的檢視交 40.

(50) 通工具的動向，若不滿意的話，可以再次規劃更完美的搭乘站點，規劃方面能更靈活的使用，且讓使用者能有不一樣的操作感受；若滿意的話，按下完成按鈕紀錄規劃行程的資訊，可以再次參考使用，如圖 3-11。. 圖 3-11 一日遊規劃行程圖 - 範例一在台北的一日遊中，其中最怕的就是交通阻塞、車位租不到和錯過列車，研究中開發出的 APP 可以尋找各項交通資訊，其中最常見的交通工具如：捷運、ubike、停車位，透過搭乘交通工具的混合使用，讓使用者可以省下大大的時間，在旅行的過程中利用此 APP 使用的資訊可以幫助遊玩時交通工具的轉換，讓到達目的地更加順暢無阻，例如開車時，可以搜尋鄰近的停車場位置進行停車的動作，免除找車位的麻煩；租借 ubike 時可以搜尋目前位置利用自己設置的範圍去搜尋範圍內的站點，而觀看租借的情況來考慮到哪個站點租借或者歸還；搭乘捷運時，使用者可以觀看目前位於哪條捷運線路的時間且查詢多 41.

(51) 久會到達以及票價查詢起點到達目的地的價錢和捷運站點轉站的資訊，透過位置去考慮到哪轉車，另外提供無障礙電梯資訊，幫助行動不便的人可以清楚電梯位置去搭乘，如此透過交通工具的轉換可以充實玩樂一天又可避免在美好的假期為了塞車而困擾，甚至失去興致，如圖 3-12。. 圖 3-12 交通工具應用顯示圖 - 範例一 42.

(52) 若我們不是以自行所構想的規畫行程的話，是以部落格熱門文章為例，由於網際網路的蓬勃發展，利用手機上網去輸入想要尋找的關鍵字，例如：臺北一日遊，如圖 3-13，就會顯示在網路上看到許多的熱心旅遊客在部落客分享推薦文章，在此舉例一個利用網路上推薦熱門文章來實作臺北一日遊之情境應用，部落客提供許許多多的旅遊圖片、交通方式、景點特色…等的資訊，讓想去旅遊的人可以有很多種選擇，其中本研究以此篇部落客為例，利用捷運來遊玩臺北一整天，列舉四個路線包括路線一捷運松山新店線站、路線二捷運板南線、路線三捷運中和新蘆線以及路線四捷運淡水信義線，而且詳細述說利用同條路線的捷運可以邊停邊玩邊看每個景點，避免花時間於轉車方面，當中我們採用路線二：捷運板南線來規劃此行程，如圖 3-14。. 圖 3-13 搜尋臺北一日遊資訊. 43.

(53) 圖 3-14 捷運一日遊行程資訊圖 44.

(54) 當我們從部落客推薦行程文章中選擇理想的臺北市一日遊時，則可以設想行程中更細部的情況，則是由交通工具做為考量，雖然部落客文章中有推薦大致上的搭乘方法，但其可以在加點自己所想法，讓行程的過程中更加完美，於是在選擇的行程中首先是前往龍山寺廟宇拜拜祈求萬事平安，接著搭乘龍山寺站前往東區餐廳 Mee’s Café 享受美好午餐，吃完午餐坐捷運到市政府站觀賞松山文創園區的展覽且租台臺北市政府所提供的 Ubike 來騎車順便逛街一整個下午，逛街逛到疲倦了，可以到市政府附近著名的 Akuma caca Café 下午茶，搭配入口即化的甜點，讓下午的美好行程增添些美味，晚餐搭捷運到忠孝敦化站去 VIVO 光癮時尚餐飲吃道地的西班牙料理，其環境優美、氣氛絕佳以及不可或缺的美味菜色，讓人垂延三尺，不管帶情人或家人來是個絕佳地方。再來就是研究中所提供的規畫行程功能，可以把事先做好的行程功課，輸入到 App 中，運用從臺北市政府公開資料所提供的各項交通工具給使用者做選擇，其中包括：停車場、微笑單車以及捷運站點，依據想到達的地點讓使用者自行輸入，每當輸入及選擇完成一筆資料後會立即顯示於畫面中，選擇時系統會根據地理情境資訊優先選擇離使用者最近的停車場、微笑單車以及捷運站點資訊，若輸入多筆資料，系統會根據所輸入資料的最末筆資料的地理位置來顯示離此位置最近的停車場、微笑單車以及捷運站點資訊，顯示的畫面提供給使用者地址、地點、搭乘何種交通工具到達目的地等相關資訊，可以更清楚明白行程規劃的流程，如圖 3-15。 45.

(55) 圖 3-15 一日遊規劃行程圖 - 範例二最後一切就緒就可進行行動裝置中 App 功能應用，我們可以利用各項功能查詢所有停車場、Ubike 以及 MRT 資訊，首先以此次規劃行程中 MRT 的功能中瀏覽所有捷運行駛列車，偵測目前使用者位置推薦最近捷運站點以及捷運行駛列車到站資訊可以清楚列車的動向，也提供捷運無障礙資訊，讓行動不便的民眾進行查詢動作，若不清楚捷運票價價錢，能提供依據我們所選擇的列車進行該站的票價價錢做為查詢，另外也可以觀看轉車的資訊，每站捷運列車所在的路線會依據顏色不同而行駛不同地方，臺北市捷運以顏色最為區分，例如：淡水線、新店線…等，故在地圖上有配合不同路線色而有標誌捷運站顏色，避免台北人生地不熟的民眾不易上錯車且可以清楚知道我們該轉什麼捷運路線。接著此次規劃行程中 Ubike 中瀏覽所有微笑單車站點資訊，可以根據我們所選擇任何一個微笑單車站點獲得 Ubike 的總數量以及剩餘數，而根據所選擇該微笑單車站點的數據分析圖，讓我們可以得知該站點的曲線動向以及獲得最佳租 46.

(56) 借和歸還時段，避免租車和還車的尖峰時段，導致租借車輛或者歸還車位一位難求的窘境，如圖 3-16。. 圖 3-16 交通工具應用顯示圖 - 範例二 47.

(57) 3.9 使用案例(Use Case Diagram). 圖 3-17 使用案例圖 48.