第二章 文獻探討
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：
圖片 2-4 RDF 關係描述圖
1. Location API：Location API 可以讓你在不需要專注在底層的位置辨別技術的前提下，簡單 的建立你的位置情境感知的應用。而且盡可能的減少對於手機硬體的需求，降低電源損耗。
2. Google Calendar API：Google Calendar API 可以讓你建立開發客戶端應用程式，並透過程式 創建、編輯、刪除、搜尋活動(event)。
圖片 3-3-1 系統規劃圖
第 3 章 系統規劃
本研究可分成兩部分，一部分是使用 RDF 描述台北市公開資料，建立鏈結資料，並提供一個可 以存取的平台；另一部分是利用該平台提供的資訊，實作一個 Context Awareness 的應用服務。
台北市提供各類的 Open Data，資料格式眾多，而且可讀性較差，於是本研究想建立一個 RDF Interface，將政府提供的 Open Data，藉由 Converter 統一轉成 RDF 格式的資料，並且整合不同資料集 的資料，建立起 Linked Open Data，以便達成格式統一的目的，可讀性也較佳，而且藉由鏈結資料的 連結，不同種類的資料彼此可以找到鏈結，方便進行比較、運用。RDF Interface 會提供一個 SPARQL 的 EndPoint，其他使用者可利用 SPARQL 查詢、運用這些資料，開發更多的服務讓一般的使用者使 用。本研究也會以此基礎，開發一個 Context Aware 的行動運用。
另一方面，本研究要實作的服務是『停車場資訊的查詢與推撥機制』，藉由這個服務，使用者可 以瀏覽台北市各個汽車停車場的資訊，特別是空位個數，服務中導入情境感知(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，試圖把 不同種類、或是不同政府單位的開放資料，鏈結在一起，建構台北市公開資訊的鏈結資料。
以下為擷取部分台北市公開資料部分資料所繪出的 Linked Data Diagram：
此 Open Data Diagram 有八個資料來源，分別是台北市停車場資訊(Parking Garage)、台北市急救 責任醫院(Emergency)、圖書館資訊(Library)、台北市消防局(Fire Department)、台北市警察局(Police Station)、台北市案件統計(Law Case Record)、台北市社區活動中心(Community)、台北市人口資訊 (Population Info)。這八個資料來源，除了基本的資訊，例如名稱、編號等，屬於 Info 資料，都同時具 備地址、或是行政區域(例如大安區)等 Location 資料，所以我們可以大大利用 Location，作為資料之 間鏈結都樞紐。
本研究為了專注在概念的實作，所以僅使用三種資料來源建立 RDF Interface，分別是：台北市停 車場資訊(交通運輸類，由台北市停車管理工程處提供)、台北市警察局名稱及地址(公共資訊類，由台
圖片 3-2 台北市政府公開鏈結資料圖
北市政府警察局提供)、以及台北市政府消防局各單位通訊錄(公共資訊類，由台北市政府消防局提
供)。
本研究試圖使用 RDF 描述這三種資料來源，其建立的 Linked Open Data Diagram 如下：
這個 Diagram 有三個主體：
1. Parking Garage(停車場資訊) 2. Fire Department(消防局資訊) 3. Police Station(警察局資訊) 分別由六個基本單元所組成：
1. Info：是用來描述基本的資料，例如 Name、ID 等。
2. Location：是描述地理資料，其中包含 Address、Latitude、Longitude...等。
3. Time：是描述服務時間/營業時間。
4. Contact：是電話、傳真等資訊。
圖片 3-3 台北市公開鏈結資料圖
5. Police：記錄著警局的隸屬關係。
Attribute Name Data Type Description
info:id Long 該筆資料的唯一識別
info:name String 該筆資料的名字
info:type String 該筆資料的屬性。其項目有：
context, parking, police, fire_department
表格 3-2 Data Schema - location
xmlns:loc=”http://data.taipei.gov.tw/location#”
Attribute Name Data Type Description
loc:area String 區域資訊。其項目為台北市所
有行政區域
loc:adderss String 地址資訊
loc:latitude Double 緯度資訊
loc:longitude Double 經度資訊
表格 3-3 Data Schema - time
xmlns:time=”http://data.taipei.gov.tw/time#”
Attribute Name Data Type Description
time:start String 服務開始時間
time:end String 服務結束時間
表格 3-4 Data Schema - parking
xmlns:pa=”http://data.taipei.gov.tw/parking#”
Attribute Name Data Type Description
pa:total_car Integer 停車場車位總數
表格 3-5 Data Schema - contact
xmlns:con=”http://data.taipei.gov.tw/contact#”
Attribute Name Data Type Description
con:tele String 服務處電話號碼
con:fax String 服務處傳真號碼
表格 3-6 Data Schema - police
xmlns:police=”http://data.taipei.gov.tw/police#”
Attribute Name Data Type Description
police:content String 警局所屬單位
表格 3-7 Data Schema - context
xmlns:ctx=”http://xml.csie.ntnu.edu.tw/context”
Attribute Name Data Type Description
ctx:priority Integer 優先權設定
ctx:parking_hour Integer (預計)停車時間
ctx:area String (預計)停車行政區
以下是三個主要單元的 Data Schema。
表格 3-8 Data Schema – 停車場資訊 一個停車場資訊
Attribute Name Data Type Description
info:id Long 該筆資料的唯一識別
loc:longitude Double 經度資訊
time:start String 服務開始時間
time:end String 服務結束時間
pa:total_car Integer 停車場車位總數
表格 3-9 Data Schema – 停車場即時空位資訊 一個停車場的即時空位資訊
Attribute Name Data Type Description
info:id Long 該筆資料的唯一識別 pa:available Integer 停車場空位總數
表格 3-10 Data Schema – 警察局資訊 警察局資訊
Attribute Name Data Type Description
info:id Long 該筆資料的唯一識別
info:name String 該筆資料的名字
info:type String 該筆資料的屬性。其值為:police
loc:adderss String 地址資訊
loc:area String 區域資訊。其項目為台北市所
有行政區域 police:content String 警局所屬單位
表格 3-11 Data Schema – 消防局資訊 消防局資訊
Attribute Name Data Type Description
info:id Long 該筆資料的唯一識別
Attribute Name Data Type Description
info:id Long 該筆資料的唯一識別
info:type String 該筆資料的屬性。其值
為:context ctx:priority Integer 優先權設定 ctx:parking_hour Integer 停車時間
ctx:area String 停車行政區
特別的是，實際上停車場資訊被分成兩個 RDF Dataset，理由是為了要能將空位資訊進行分析預 測，所以特別幫該資訊獨立成單獨的 RDF Dataset。實作時，會依據給定的時間點，把對應的空位個
數資訊整合成完整的停車場資訊，再進行 Query。
3.2 情境感知(Context Awareness)
我們希望利用手機的 Sensor，即時獲得使用者的「時間資訊」以及「地理資訊」，並且以此為基 礎，提供符合此情境的運用。基於上述規劃的 Linked Data Diagram，我使用的是『停車場資訊』開發 情境感知行動應用。在這個應用中，使用者的時間、位置資訊會傳送給 Server，Server 依據此情境，
提供符合的停車場資訊。例如：使用者下午 3 點要去台北 101 開會，則服務會提供位於信義區的停車 場資訊以及該停車場下午 3 點的空位資訊。
本研究會實現兩種模式的情境感知應用，分別是『依據情境規則』以及『依據 Calendar Event』。
首先是『依據情境規則』模式，我們會建立一個 Context Management 系統，讓使用者設定自己 的『情境規則』。這裡的『情境規則』設定，就是實踐基於 Time-based 及 Location-based 的情境感知 服務。當系統進行情境感知搜尋的時候，會依據該設定，推播想要的消息。這裡規劃三種情境規則：
『依據Calendar Event』模式提供了第三種情境：Event-based，希望由特定的「事件」驅動服務，
本研究使用的是線性組合預測法(Linear Combination of Forecasting)。我利用目前的空位預測值，
以及實際空位個數，求出新的預測值，其公式如下：
本算法有兩個變數：『目前的預測空位個數』、『實際空位個數』；有一個操縱變因：p，作為
第二個試算，令 p 值為 0.8，空位預測值設定為 10，經過 6 個單位時間後，其預測值的變化如下
3.4 使用案例圖(Use Case Diagram)
這個系統有兩個Actor，一個是「一般使用者」，一個是「情境感知系統」。有四個案例：「瀏 覽合適停車場」、「主動推薦合適停車場」、「Rules新增/刪除/查詢」、「分析空位資訊」：
1. 瀏覽合適停車場：此系統提供最基本的瀏覽功能，使用者可以利用系統，依照需求直接瀏
覽任一時間點、任一台北市停車場資訊。
2. 主動推薦合適停車場：使用者可以設定情境規則，當使用者的情境資料符合設定的規則，
系統就會「主動推撥」適合的停車場資訊。「主動」的意思是，使用者不用開啟應用程式，
就會利用Android手機的推撥機制，將訊息推薦給使用者。例如：使用者期望能知道公司 附近(信義區)上班時間(8點)的附近停車場空位訊息，當時間接近8點，使用者開車進入信 義區附近，系統就會主動推撥最多空位的停車場，呈現在Android手機的通知列，使用者 不用再自己瀏覽、搜尋。
圖片 3-7 使用案例圖
3. Rules新增/刪除/查詢：使用者可依據自己的期望，自由的設定自己情境規則，也可以隨時 瀏覽、刪除這些情境規則。
4. 分析空位資訊：系統會持續追蹤台北市停車場即時空位資訊，並且將其資料加以分析，以
建立停車場空位預測模型。
3.5 活動圖(Activity Diagram)
根據 Use Case Diagram 的各個案例，歸納出數個 Activity Diagram。以下分別介紹。
3.5.1 瀏覽合適停車場
圖片 3-8 活動圖 – 瀏覽合適停車場
1. 使用者進入系統
2. 選擇篩選的條件。本系統有兩個參數可以選擇：「區域」以及「時刻」。「區域」是指台北
市的各個行政區，使用者可以選擇瀏覽特定行政區的停車場資訊，或是選擇全部瀏覽；「時 刻」是以『小時』為單位，可以瀏覽0~23時，不同時刻的停車場資訊，包括空位資訊。因為 本系統已經建立好空位預測模型，所以即使不是當下的時刻，抑或是當台北市政府公開資訊 進行維修時，本系統仍然可以提供自己預測的各個停車空位個數，確保服務的進行。
3. 傳送情境資料給Server
4. Server依據該條件搜尋符合的停車場 5. 將結果傳回至使用者Device
6. 呈現在螢幕上。
3.5.2 使用者瀏覽情境設定
1. 使用者進入系統
2. 打開瀏覽情境規則的頁面
3. 向Server要求目前所有設定的情境規則
3. 向Server要求目前所有設定的情境規則