1

經濟部工業局 107 年度

期末專案執行成果報告

計畫名稱：推動跨國資料共通應用計畫

執行期間：

全程：自 107 年 3 月 1 日至 107 年 11 月 30 日止

本年度：自 107 年 3 月 1 日至 107 年 11 月 30 日止

主辦單位：經濟部工業局

執行單位：財團法人工業技術研究院

2

第 1 部分目錄

頁次

第 1 部分 計畫執行成果摘要表………………………..………1

3

第 1 部分 計畫執行成果摘要表

組別 知識服務組

計畫名稱 推動跨國資料共通應用

受委託單位 財團法人工業技術研究院

政府經費(元) 7,000,000

計畫中文摘要

深化與亞洲開放資料合作夥伴「資料分析平台與應用合作」協議，輔

導國內資料產業(企業、社群或新創團隊)，透過實證台泰跨國協作水利防

災資料互通技術及共通 API，以及建立台泰智慧水利防災資料混搭應用合

作，有效於技術面與資料面與各國進行實質合作。

同時協作技術導入國內企業應用產品，並與泰國組織或機構完成資料

互連驗證，推動資料互通分享並帶動應用服務發展，提升國內產業國際資

料服務能量，拓展國際數位經濟商機，為計畫的重點。

計畫以推動跨國資料共通應用為主軸，執行成果項目有：(1) 擴展促

成國際合作資料應用案例；(2) 深化跨國資料處理技術與工具。產出與效

益為(1) 建立 1 個跨國資料混搭應用合作示範案，與國內外各至少 1 個組

織、機構或企業進行資料互連驗證；(2) 推動至少 1 個領域別跨國資料共

通 API 格式標準，擴增 1 個領域別跨國開放資料互通技術及規範，擴建 1

個領域別共通語彙基盤，及擴增 DCAT-AP Data Model。

4

第 2 部分目錄

頁次

第 2 部分 計畫執行報告

一、計畫目標、計畫架構與執行內容 .................................... 5

(一)計畫目的與預期成效 ................................................. 5

(二)計畫構想 ..................................................................... 7

(三)計畫架構(含樹狀圖) ................................................ 8

(四)計畫主要內容 ............................................................. 9

二、計畫已獲得之主要成果與重大突破(含量化成果 output)

............................................................................................ 93

三、主要成就及成果之價值與貢獻度(outcome) .................. 94

四、跨部會協調或與相關計畫之配合 .................................. 94

五、檢討與展望 ....................................................................... 95

5

第 2 部分 本計畫執行報告

一、計畫目標、計畫架構與執行內容

(一)計畫目標及預期成效

目前面臨發展數位國家創新經濟競爭力之資料來源與技術

端之市場存量過小，希望藉由增量國際的資料，來補足未來資

料經濟發展所需流量規模。倘若能掌握國際資料，則不但可藉

此強化產業跨國的交流合作，更可帶動資料經濟的國際發展與

商機。資料流通可加速資料創新應用與帶動經濟發展，因此，

若能建構不同國家、不同語言的資料互通標準、語彙，以及互

通 API 來加速資料流，是未來發展的重要課題之一。

在目前推動開放資料國際合作的基礎下，經濟部已成功推

動亞太 6 個國家共同成立「亞太開放資料合作夥伴」(AODP)，

並在今年全球開放資料會議中發表亞洲區域合作之構想。作為

AODP 的祕書處，國內已奠定與亞洲各國共同合作契機，也具

有主導亞洲區域議題之能力，因此本計畫可更進一步推動跨國

資料互通，在技術面將建構專業領域共通詞彙基盤，優化跨國

資料品質管理模組。在應用面則擴增跨國開放資料平台鏈結，

創新跨國資料混搭應用。同時在國際技術合作面：強化國際合

作與議題推動，推動資料產業技術國際交流。藉由三管齊下，

推動國內資料產業接軌國際，跨入國際資料應用市場，厚植國

際數位經濟競爭力。這是國內重回國際經貿舞臺並占有重要一

席之地的機會，也正能呼應政府新南向政策。

本計畫目標相關過去、現在、未來的關聯性：

• 106 年推動跨國資料互通計畫，整備跨國資料技術，跨國單

專業領域別資料鏈結互通技術之可行性驗證，如完成台日

農業活動 (Agricultural Activity) 資料鏈結互通技術驗證。

• 107 年推動跨國資料共通應用計畫，複製跨國資料技術，結

合產業擴增新領域別跨國資料互通與實證，如經台泰協作

水利防災資料應用案結合防災產業，協作技術導入國內多

家企業應用產品，推廣水利防災產業資料共通知識本體，

6

並與泰國組織或機構完成資料互連驗證，已經取得究心公

益科技團隊與亞洲減災中心（ADRC）簽署國際防救災領域

合作備忘錄成果，達成新南向國際交流敲門磚。

• 108 推動跨國資料共通應用計畫，擴散跨國資料技術，結合

產業擴增至多國間專業領域別跨國資料互通與實證，且協

助產業取得國際合作商機，如結合防災產業，串聯湄公河

沿岸國家(如：泰國、越南等)進行跨國水利防災資料互通與

實證，目標預計協助產業取得更豐碩國際商機。

其核心價值為推動跨國開放資料流通服務，讓資料產業找

到國際資料、分享國際資料、使用國際資料，解決資料產業跨

國、跨領域、標準化需求，以降低處理資料時間及成本、跨領

域資料整合應用門檻。

推動國際合作開放資料混搭應用時，

• 需透過鏈結開放資料(LOD)技術建構專業領域共通語彙

Open API 串連存取無障礙資料應用情境。

• 整合在國內產業鏈能量聚集帶動資料混搭流通多元資料應

用服務面向。

深化與亞洲開放資料合作夥伴「資料分析平台與應用合作」

協議，輔導國內資料產業(企業、社群或新創團隊)，透過實證

台泰跨國協作水利防災資料互通技術及共通 API，以及建立台

泰智慧水利防災資料混搭應用合作，有效於技術面與資料面與

各國進行實質合作。

同時正協作技術導入國內企業應用產品，並與泰國組織或

機構完成資料互連驗證，推動資料互通分享並帶動應用服務發

展，提升國內產業國際資料服務能量，拓展國際數位經濟商機。

7

(二)計畫構想

圖 1 計畫構想

本計畫構想活用共通語彙知識本體為推動核心，透過建立

跨國開放資料共通 API 規範與平台實踐，鏈結開放資料(LOD)

技術建構專業領域共通語彙 Open API 串連存取無障礙資料應

用情境，以及整合在國內產業鏈能量聚集帶動資料混搭流通多

元資料應用服務面向。推動期間區分為三個階段如下：

1.技術與工具研發，整備技術與工具

以推動跨國開放資料流通服務概念性 (Proof of Concept；

POC)，驗證找到跨國資料、分享跨國資料、使用跨國資料架構

否能確實執行，解決資料產業所面臨跨國、跨領域、標準化需

求，有助於降低處理資料時間及成本、跨領域資料整合應用門

檻之效益。

2.應用服務驗證，國際合作開放資料混搭應用

透過逐佈建各專業領域(如農業、防災、交通運輸、選舉、

智慧城市等)共通語彙知識本體進行應用服務驗證，驅動產業輔

導與實質國際合作，著手於從單點主題串連產業鏈形成國際資

料經濟生態系之商業驗證。

3.國際合作，推動產業銜接國際合作與交流

協同產業銜接國際合作，推動各專業領域服務擴散與交

流，使得產業應用驅動技術研發，協作促進產業國際競爭力動

能，放眼國際資料加值，爭取國際商機。

8

(三)計畫架構

圖 2.計畫架構

本案計畫執行架構之分項計畫及內容說明：

1. 擴展促成國際合作資料應用案例(權重：65%)

• 建立 1 個跨國資料混搭應用合作示範案

• 與國內外各至少 1 個組織、機構或企業進行資料互連驗證

2. 深化跨國資料處理技術與工具(權重：35%)

• 推動至少 1 個領域別跨國資料共通 API 格式標準

• 擴增至少 1 個領域別跨國開放資料互通技術及規範

• 擴建至少 1 個領域別共通語彙基盤

9

(四)計畫主要內容

1. 規劃內容

擴展促成國際合作資料應用案例

工作項目 內容說明

(1) 建立 1 個跨國資料混搭

應用合作示範案

(1.1)至少促成 2個國家參與水利防災國際

合作洽談事宜

(1.2)完成建立台泰跨國資料混搭應用合

作示範案。

(1.3)目標預計可協助產業取得約新台幣

400萬國際商機。

(2) 與國內外各組織、機構

或企業進行資料互連驗

證

(2.1)完成導入 1家國內防災廠商使用跨國

資料共通 API，並簽署合作備忘錄。

(2.2)完成與國內外各至少 1個組織、機構

或企業進行資料互連驗證，至少簽署

合作進行資料互連驗證備忘錄 1件。

深化跨國資料處理技術與工具

(1) 推動至少 1 個領域別跨

國資料共通 API 格式標

準，本期新增共通知識

本體及上期台日互通農

業活動資料的知識本體

API 使用次數總合預期

增量達到 15,000 次以

上，且協助廠商處理跨

國資料降低 30%的時間

與成本。

(2.1)完成推動台泰跨國水利防災資料共

通 API格式標準程式，解決資料產業

跨國、跨領域、標準化需求，降低處

理資料時間及成本、跨領域資料整合

應用門檻。

(2) 擴增 1 個領域別跨國開

放資料互通技術及規範

(中文版)

(2.2)完成擴增水利防災資料鏈結互通相

關技術及規範中文版 1份。

(3) 擴建 1 個領域別共通語

彙基盤

(2.3)完成擴建台泰相互對映與連結水利

防災知識本體之語彙 1份

(4) 擴增 DCAT-AP Data

Model

(2.4)完成開放資料整合平台擴增 DCAT-AP

Data Model，並提出執行報告 1份

10

2. 實際執行方法

(1).工作項目實際執行情形說明

A. 擴展促成國際合作資料應用案例分項計畫執行成果

(A) 建立 1 個跨國資料混搭應用合作示範案

a 完成 2 個國家水利防災國際合作洽談，並提供執行成果報告

已參與 Secutech 2018 台北國際安全科技應用博覽會之國際

展示活動，並邀請泰國、越南、菲律賓及尼泊爾參加推動跨

國資料共通應用會議，促進跨國資料共通合作交換意見，使

各項水利防災資料應用服務之成果，得以透過實質活動之辦

理，增加跨國洽談機會，提升合作商機，並提供執行成果報

告 1份(含會議記錄)。執行成果說明如下：

(a) 宗旨：本活動目的透過參與國際展示活動，並邀請東南亞

各國機關(構)參加推動跨國資料共通應用會議，促進跨國

資料共通合作交換意見，使各項水利防災資料應用服務之

成果，得以透過實質活動之辦理，增加跨國洽談機會，提

升合作商機。

(b) 活動日期：107年 4月 25-27日

(c) 會議地點：Secutech 2018 台北國際安全科技應用博覽會

之國際展示活動，臺北世貿南港展覽館 1F

(d) 展示區位：如下圖示

11

圖 3.展示區位圖

(e) 展示方式

展示方式為展場之標準攤位採用組合式隔板及方柱型展台呈

現，每一個單位含三個投光燈、二面海報展示版一個電源插

頭及一個組合式展示面板與桌子，另一面架設電視可輪播計

畫成果簡報。如下：

12

(f) 會議記錄

• 由於配合經濟發展之所需，各國國內以資通訊科學為基礎的

開放資料日益受重視，對於開放資料的前端已陸續參與國際

相關社群，對於跨國的相關合作可以請台灣協助提供既有之

經驗。

• 泰國及越南對於防災資訊之應用，近年來數次觀摩台灣經

驗，如應變、整備之相關措施，但對於資訊面的跨部會整合，

而至於跨國協作整合等，尚待開始，若以既有研發資訊可供

測試樂觀其成。

• 各國之防災的重點皆以人身安全保障為首，目前泰國亦有水

患災害，可以利用水患防災語意層導入泰國之防災資訊平

台，分析水文環境、水文事件及水文觀測等層級，可以提高

資料互通之可操作性，亦有助於擴大泰國防災平之效益。

• 關於未來安排之合作交流會議泰國防災減緩局表示歡迎，合

作備忘錄之簽定可以請工研院擬定參訪交流議題及合作備

忘錄內容，再行聯繫。

• 越南已經選定導入坡地防災監測機制，若另一方面可以加入

此防災語意建置，與災害感測物聯資訊結合，必是防災作為

之積極創新代表，未來之合作可以再進一步洽談。

13

• 對於語意發展 Linked Data 之實作與服務發布，可在回國後

與技術單位再行協商各項發布機制之可行性。

• 菲律賓與台灣皆為島國，颱風水患頻傳，雖無連結其他國

家，但在開放式語意機制之建立未來亦可以水災及水資源管

理為示範，建立此有助於防災之整備架構。

• 尼泊爾與台灣水利之學術單位交流頻繁，在防災模擬及模式

之設計若能加入水利防災語彙之混搭技術，可能有加乘的效

果，但需要該國內資訊管理單位協助整合。

• 尼泊爾表達其在自然環境、水災類型與課題上與台灣相似，

希望能更近一步了解資料示範應用及相關水災應用之成效。

• 亞洲開放平台為目前重要的共享平台，各國參與之積極度雖

有差異，但應用研究之協定及資料鏈結互通有一定之程序規

範，各國可先行研析，做為日後發布服務之參考。

針對多元多國合作之後續追蹤與合作可行性之驗證與說明

如下：

• 泰國政府 DGA 正積極洽談進一步發展防災領域- 災害恢復

平台等雙邊合作方案。

• 越南越南地質與礦產研究所以越南水患事件為例，表示有意

願參與於 108 年度協作台越跨國水利災防資料混搭應用案

例。

菲律賓及尼泊爾對建立水資源管理資料混搭應用案例有興

趣，正與該國內資訊管理單位協助整合洽談中，尋求日後雙方合作

機會。

b 提出泰國訪問團規劃報告

已於 2018/05/23 向工業局提出泰國訪問團規劃報告，執行重點摘

14

要如下：

(a) 與社團法人台灣防災產業協會合作，組團共赴泰國訪問，

其主要目的

• 交流台泰防災經驗，建立台泰協作聯繫管道。

• 確認在地防災管理制度及治理技術需求，落實防災產品化及

達到服務在地化可行性。

• 鏈結國內防災廠商與外國政府機關、廠商及在地人脈，拓展

未來商機。

• 與泰國相關單位簽署水利防災合作/協議意向書。

• 連結國內防災廠商與外國政府機關. 廠商及在地人脈，拓展

未來商機。

(b) 組團方式—邀請產業選商方式

• 實際具水利防災之產品、執行專案經驗者。

• 具國際交流及跨國合作潛力之廠商。

• 社團法人台灣防災產業協會會員及合作夥伴。

• 新南向(越南、泰國等)已有成果及人脈者。

(c) 凝聚產業能量

• 由工研院帶領籌組臺灣產業代表團赴泰

• 凝聚各廠商之研發技術與能量代表廠商共國內 12 產業

單位，16 人次，拜訪 5 個官方及學術單位，於參訪行

程中參與交流

• 提供各廠商相關技術輸出或海外代理之機會

15

圖 4.工研院帶領籌組臺灣產業代表團赴泰

(d) 參訪議程安排

本計畫於 4 月起即積極與泰國各單位進行聯繫，並順利於

6/25 出發至泰國曼谷進行為期三天的交流行程。

每一場次由臺灣防災產業協會周天穎理事長說明本次參

訪目的，並逐一介紹本次參訪團員與各參與單位，讓泰

方該單位瞭解各廠商於防災相關產品服務及特色。

由巨資中心黃副主任報告工研院防災資料跨國合作計畫

之內容。

(e) 參訪成果

電子化政府局 (DGA)表示台泰雙方的合作，特別資料標

準及互通，應用領域著重於災害預防、水資源或糧食安

全之議題；明年單位有編經費，可促進雙方合作商機。

內政部內政部防災減緩局 (DDPM)是由不同單位收集災

16

害類型資料且開放共享使用，透過資料分析災害預防，

目前所面臨問題在於各單位的資料格式不同，如何實際

使用待解決，後續雙方可以 LOI 方式持續進行資料標準

及互通合作。

內政部公共城鄉規劃局 (DPT)對於參訪團隊災防應用產

品有高度關注，尤其智慧城市在開放資料平台及物聯網

感測資料整合應用商業化。

水利和農業信息學研究所(HII)，願意協助媒合的當地合

作企業，協助簽訂 MOU 及協助提供泰國的資料集。

亞洲理工學院 (AIT)，願意扮演台泰防災應用軟硬體研發

及國際軟體訓練中心的角色，對於工研院水利災防共通

語意系統之跨國資料互通有興趣，雙方可以 LOI 簽署及

協助此資料應用系統與後續推廣。

GIC 中心談及日本東京大學採用語意技術建立水文知識

本體研究，提議透過日本東京大學建構台灣、泰國、日

本三方技術合作關係。

此次台泰跨國合作成功的關鍵因素，在於找到對合作單位

及聯繫窗口，以及搭配熟悉水利防災領域的防災協會為

合作夥伴，發揮串聯跨國間技術合作交流，共同創造國

際商機。

延伸之擴展其他南向國家合作的可行性、議題與合作方式

之評估方式可依此模式，擬定推動南向國家合作之整體

推動策略與做法，前期整備技術與工具，同時凝聚產官

法資源及分享資訊，多管道同步協作溝通及掌握泰國官

學需求，聯合發揮跨國間技術合作交流，共同創造國際

商機。

本案以秘書處做為統籌窗口持續合作，努力完成正式台泰

17

共識文件之擬訂或簽署，以發揮互利雙贏的合作遠景，

以作為績效認定指標。同時持續努力媒合成其他東協國

家合作意願之簽署。

c 完成建立台泰跨國資料混搭應用合作示範案。

根據本計畫「台泰智慧水利防災資料混搭應用合作示範」，

工作重點可分別為以下項目：

(a) 建立台泰水利防災語意模型

資料面應用國際標準語彙，推動台泰協作跨國水利防災領域

別，開發至少 3 項水利防災領域別跨台泰資料共通知識本體

API (水災事件知識本體、水文觀測知識本體、水文環境知識

本體)，蒐集且鏈結互通台泰水利災防領域開放資料，進行

Linked Data之實作，並發布為 SPARQL Endpoint。引用國際

標準 Sensorthings API為觀測資料以標準格式對外發布。

(b) 確立跨國水利防災開放資料且建立示範應用案例

應用上述資料服務及平台框架完成台泰水利防災資料語意互

通對應機制，開發台泰水利災防智慧應用示範 APP(或 Google

Ext.)，有助於未來台泰共同發展管理策略模擬等應用服務。

同時，建立台灣及泰國共通語彙範本，提升後續資料互通之

互操作性。並將其建置於本計畫所開發之 CKAN平台。

針對上述之工作項目中的挑戰與問題，以利尋求解決辦法，

其問題分析與對策如下：

I. 水利防災在國內即為跨部會、跨領域之複雜問題，實務應

用往往非單一資料來源即可解決，因此在資料格式與資料

模型整合上一直也是費時費力的工作。本計畫執行受限時

間與成本限制，將以在國家災害防救科技中心所制定之

18

CAP TAIWAN Profile 較為成熟與普及於災害示警相關應

用，因此將針對 CAP標準作為語意模式建立之示範，提供

水災事件知識本體，並以此建置經驗拓展至水文觀測知識

本體及水文環境知識本體。

II. 由於泰國在政府開放資料之面向與品質皆不如國內，因此

在水利防災領域之開放資料來源較為缺乏(目前泰國政府

開放資料集約 1600餘筆)，因此將持續與泰國防災減緩主

管 部 門 (Department of Disaster Prevention and

Mitigation)持續溝通，並提供台灣水利防災相關開放資

料清單予泰方參考，並透過合作意願之簽訂請泰方協助蒐

集資料。

III. 在示範應用開發部分，因受限泰方可取得之資料完整

度有限，將設計提供 Chrome Extension 或簡易的 Web 應

用程式，供使用者線上檢視氣象預測及水災事件資料。

IV. 台泰語言、文字及文化、管理權責之差異為應用服務無法

有效互通的主要原因，本計畫也將近一步地研究如何透過

語意技術將相同概念不同表述之主體進行鏈結，雖然目前

台灣及泰國針對水利防災資訊仍尚未標準化，可能造成資

料鏈結上的困難，以及跨國資料互通的障礙，將透過實證

方式提出可能的解決途徑。

(c) 系統架構規劃設計

I. 工作執行流程

由於泰國方可蒐集之資料較不明確，將針對台灣過去在防

災經驗上所應用之資料進行盤點後，針對台灣及泰國兩方

資料進行蒐集，並同步進行 CAP Ontology 之建置。待資

料蒐集完成後再進行資料清理作業，將台泰資料透過

CAP OWL 進行 D2R 之結構轉換後匯入

19

BrightStarDB(Triple Store)，並對外發布支援 SPARQL 查

詢語法之 RESTful API。

在水文觀測部分，以雨量作為示範案例，除因雨量觀測為

各國較為基礎之即時監測資料外，雨量亦在水利防災中扮

演重要角色；針對水文環境部分則以台泰之「流域環境」

進行後續資料蒐集及知識本體建置作業。

圖 5.語意轉換及資料發布流程設計圖

II. 系統架構及情境設計

本計畫依據災害、水文觀測、水文環境三大知識本體之架

構與對應台、泰資料集設計查詢情境，並實作於企業數位

科技之 GeoSense Map 產品功能，提供 SPARQL 查詢模

20

組，除了讓空間圖台產品能無縫地透過 SPARQL Query

查詢台泰水災事件資料外，亦可透過空間關聯機制，找出

水災事件周圍的避難據點，本項實作主要目的係為傳達在

知識本體之架構下，驗證既有台灣之水利防災資訊產品

（或應用程式）可透過 SPARQL 查詢方式，在無須變動

程式架構及撰寫邏輯下進行快速切換。

本計畫之應用情境開發成果結合了企業現行地理空間資

訊產品為基礎，技術協作導入水利災防資料之共通語意

API，針對臺泰水災事件資料建立歷史災害瀏覽，應用企

業既有地理空間圖台功能及架構下，將底層資料存取機制

將改為應用知識圖譜之查詢邏輯，提供災害事件大事記及

水文環境之線上檢視歷史災情之查詢系統，可提高精準歷

史災害事件地點查詢，此外透過彈性的 SPARQL API 設

計，使用者可隨意地變換查詢條件而毋需修改或重複開發

程式，而且以此歷史災情地點之 5 公里至 10 公里為中心，

可同時在地理空間圖台帶出周遭災害應變及調度資訊(如

消防隊、避難所等)供救災使用，此前台可於國內實作資

料共通 API 試驗證後，逕行切換於泰國進行跨國資料共

通 API 互連驗證展示。

21

圖 6.示範案建立之系統架構圖

圖 7.示範案欲建立之系統架構圖

22

圖 8.為一套基於開源架構之 WebGIS 圖台產品，具備快速嵌入、

架構完整、豐富互動功能等特色。

透過圖台新增的 SPARQL 模組可查詢 CAP、OBOE 觀測

及環境知識本體之鏈結資料，並可透過選擇本計畫建立之

查詢 API 或依據查詢情境自行調整 SPARQL Query 之內

容，進而鏈結查詢結果，並展示於圖台。此外因 SPARQL

API 彈性查詢之特性，在查詢結果亦可依使用者查詢需要

改變產出資料結果，包括欄位數量、名稱，甚至內容混搭。

圖 9. 透過新增的 SPARQL Query 模組，可無縫地查詢台、泰水災

事件資料，並呈現於既有圖台產品。

23

圖 10. 透過 SPARQL 模組查詢，圖片右方為查詢模組及 SPARQL

Query、左方為依據 SPARQL結果動態解析展示之空間位置。

• 泰國水災事件情境之資料應用情境

圖 11. SPARQL 之優勢讓既有功能在無需調整情況下，即可查詢

24

不同資料結構、語系的資料來源，圖中呈現為泰國降雨事件

資料。

圖 12. 圖、文互動展示泰國洪水事件資料

圖 13. 查詢結果可將泰國洪水事件資料，依據空間位置鏈結附近

避難據點，亦可查詢該據點細部資訊。

25

• 台灣水災事件情境之資料應用情境

企業協作技術導入既有地理空間圖台公版產品，可提供跨國災情

查詢，且災情地點之 5 公里至 10 公里為中心，可同時在地理空

間圖台帶出周遭災害應變及調度資訊(如消防隊、避難所等)供救

災使用

圖 14.選擇淹水警戒，並設定時間區間可從空間上看出水災事件

分佈。

圖 15. 點擊淹水事件，可查詢附近避難據點及消防設施據點。

26

• 以 OBOE 架構所描述之水文觀測資訊(雨量)為例

更可清楚看出在相同架構下可同時查詢台、泰共通性資

料，使用者可透過篩選大於 20mm 以上時雨量之降雨事件，

找出記錄到暴雨的測站。

圖 16. 圖中點位即為台、泰今年度暴雨事件之測站點位資訊。

圖 17. 透過水文觀測亦可連結查詢周圍水庫、河川資訊，搭配防汛

應變之綜合資訊查詢

27

(B) 與國內外各至少 1 個組織、機構或企業進行資料互連驗證

a 完成導入 1 家國內防災廠商使用跨國資料共通 API，並簽署

合作備忘錄。

已於企業簽署使用台泰水利災防知識本體共通 API，且協作

技術導入國內企業應用產品(企業圖台公版/監測公網)合作

備忘錄，雙方擬就水利防災語意資料應用系統進行交流與合

作，以達成互利雙贏之目標。以台泰智慧水利防災資料混搭

應用示範案例，透過資料互通技術及共通 API導入企業現行

產品，逐步發展跨國資料混搭應用，經過跨國協作資料互通

應用服務實證可行性，循續與業者合作建立運營商業化模

式，以爭取國際商機。

b 完成與國內外各至少 1 個組織、機構或企業進行資料互連

驗證，至少簽署合作進行資料互連驗證備忘錄 1 件。

本計畫依據工研院已於 2015 年已與泰國 EGA 簽訂巨量資

料合作協議，已將資料混搭技術介接與應用列入合作項目，未來

雙方將建立共通資料混搭技術標準並於東協/亞洲進行推動，此訪

談確認後續發展重點將工業局資料經濟計畫，以資料為主軸，提

出雙邊合作方案，特別是在資料標準及互動的部分，應用領域則

著可著重於災害預防、水資源或糧食安全之議題，持續台泰雙方

的合作。

完成簽署 LOI (Letter of Intent on Cooperation) -台泰簽署協作

台泰跨國協作水利防災資料互通應用研究協定)文件，且已經在

AIT 的 External Relation Office 辦程序中，AIT 希望強化台泰互動

合作頻率，每季定期開會，然後每兩年 Review 合作成果。

透過本次跨國交流活動, 與泰方當地企業對於台灣防災產品

28

前端感測與後端開放軟體產品(企業圖台公版/監測公網)之結合應

用，有相當之導入意願，擬透過前端的防災感測設備，將災害事

件即時進行存取資料，以及該事件亦可進入 Sparql 圖台，將防災

硬體與防災軟體進行整合，如此可加值防災產品的使用效益，另

一方面 Sparql 圖台亦同時可以具備主動式災害事件擴充, 作為

linking data 的基礎，擴充資料鏈結的效益。

泰方當地企業擬規劃代理台灣防災產業的相關物聯網監測產

品, 然硬體的設備必須搭配軟體的技術使前端資料的接收與後端

軟體的紀錄分析能相互鏈結，提升硬體產品的加值效益，故本計畫

所開發的共通 API即為良好的軟體介接橋樑，對未來產品的銷售及

產值的提升有相當之助益.。

(C) 深化亞洲開放資料合作夥伴 (AODP)互動成果

透過在韓國舉辦亞洲開放資料合作夥伴 (AODP) 會議，在「全球

資料」議題中，由臺灣 Open Data 聯盟陳奕廷副會長就台灣開放

資料應用與商機成功案例進行分享，並提出四點建議，專注於專

業、用不一樣的思維切入資料應用服務、尋找全球各領域方面的

資料需求(水利災害、農業、財經、交通、天氣、觀光...等)、建立

資料平台以蒐集交換資訊與需求。

另外，提供開放資料供跨國黑客松活動使用如下：

• 國外資料：日本農林水產省資料集

農業、林業、水產業、食料、防災、科研、觀光、統計調查

資料。

• 農業知識本體及鏈結開放資料集

(台灣)產銷履歷農產品。

(台灣)通路商。

(台灣)日本作物及產地。

29

• 水利防災知識本體及鏈結開放資料集

水災事件。

水文觀測。

水文環境。

B. 跨國資料處理技術與工具分項計畫執行成果

(A) 推動至少 1 個領域別跨國資料共通 API 格式標準

完成推動台泰跨國水利防災資料共通 API格式標準程式，解決

資料產業跨國、跨領域、標準化需求，降低處理資料時間及成本、

跨領域資料整合應用門檻。相關完成跨國資料處理與工具如下：

Linked CAP(Common Alerting Protocol) Endpoint，參考網址：

http://thedatahub.org.tw:8890/sparql。

擬定本計畫期間至少開發 3項水利防災領域別跨台泰資料共通

知識本體 (水災事件知識本體、水文觀測知識本體、水文環境知識

本體) API，其格式標準符合相關水利防災領域資料互通技術及國

際標準，以章節下說明相關共通知識本體技術原理及標準 API設計。

a 知識本體

本 體 論 (Ontology) 一 詞 是 由 亞 里 斯 多 德 (Aristotle) 在

Metaphysics IV，1 中所提 出，為哲學之一個分支，是研究「在」

本身的問題，即一切現象事物的基本特質。哲 學家所探討的問

題著重在於「 在是什麼?」、「在的特徵是什麼?」和「在所歸類 的

共同特徵是什麼?」等一系列形而上學的問題。然而，本計畫中的

「知識本體」 (Ontologies)一詞，並非在哲學領域的討論，而是

資訊工程中用來定義資料本身語意 (Semantics)的方法，

Guarino(1998)為了區分哲學和資訊科學中的知識本體不同，建議

哲學領域所使用的知識本體為英文大寫單數的專有名詞

Ontology，而資訊科學所使用的知識本體為英文小寫複數一般名

30

詞 ontologies，也就是說，將知識本體(Ontologies) 視為資訊的一

種。而知識本體的的建立即是知識工程，是知識呈現的技術與方

法，Noy and McGuinness(2001)認為建立知識本體應該定義 A.知

識本體中的類別 (Classes) ； B. 安排分類體系中的類別

(Subclass–Superclass)； C.定義屬性(Slot)和描述這些屬性的允許

值；D.給實例(Instance)填入屬性的值。

就知識工程的方法，他們認為知識 本體的建立應包含三個

步驟：A.定義領域和範圍；B.考慮重覆利用；C.列舉本質中的詞；

D.定義類別和層級；E.定義屬性；F.重新定義屬性；G.建立實例。

Gruber(1995)提出用框架和第一階邏輯(First Order Logic)來建立

知識本體，並定義 5 種基本要素：類別 (Classes)、關係

(Relations)、功能(Functions)、正規的原則(Formal axioms)和實例

(Instances)。而知識本體(Ontologies)根據表達方式有不同的正規化

(Formal)程度，如果表達成自然語言，知識本體可以是高度非正

規的；如果表達在一個限制和結構的自然語言形態中，則是一個

半非正式的；如果表達在人工和正規定義的 語言，如 RDF 和

UML，是一個半正規知識本體，而如果一絲不苟地以正規的屬性

的語意(Semantics)、定理(Theorems)和證據(Proofs)來定義知識本

體中的詞，則是 一個完全正規的知識本體，如第一階邏輯

(Uschold and Gruninger，1996； Gomez-Perezet al.，2004)。

隨著，語意網技術的發展，W3C 已製定了知識本體的語言

OWL(Web Ontology Language)，其中使用描述性邏輯(Description

Logic) 來定義語意，目前大多數知識本體的建立皆以 OWL 為

主，只是在格式上採用較為簡單的 Turtle 或 N3。而知識本體的建

立工具則以 Protégé 為最多人使用。

b 鏈結資料

31

自 1990 年起，世界各國相繼推動電子化政府，將政府資訊

服務結合網際網路，以強化行政效率及和民眾間的互動。因此多

國政府投入推廣開放政府資料（Open Government Data，OGD）

服務(Hendler et al.，2011； Shadbolt et al.，2011)，例如美國政府

於 2009 年推出 OGD 服務網（Data.gov），英國政府於 2010 年推

出 Data.gov.uk。考慮到發布資料的格式可能存在不相容問題及資

料結構化程度不同，可能造成資料難以重複使用，因此各國常使

用前述鏈結資料規範準則五顆星，作為資料品質評估的指標。為

了能提供政府部門及民眾有效率存取開放資料，美國政府創立

Data.gov 平台時便建立鏈結資料，例如美國聯邦環境保護署已建

立超過 130 萬筆包含設備（facilities）及物質（substances）的鏈

結開放資料。國外也有許多民間產製的鏈結開放資料，比較有名

的有 DBpedia 及 Open Library 等網站。DBpedia 位居 LOD Cloud

圖的中心位置，從 Wikipedia 擷取結構化內容，並將這些結構化

內容發布於 Web。DBpedia 可讓使用者檢索 Wikipedia 資源屬

性，並能連結到 YouTube、紐約時報（New York Times）等其他

資料庫。

Open Library 是 Internet Archive 下的一項前導計畫，標榜

"One web page for every book"。目前已收集超過 3，000 萬筆書

目紀錄，其中包含超過 100 萬筆的免費電子書可供線上閱讀或

下載。Open Library 提供了應用程式介面 API 讓全球程式設計

者得以運用其資料，使用者亦可下載每筆書目資料的 RDF 格式

檔案。

32

圖 18. pen Library 中書目查詢及對應 RDF 文件(部分)

c 鏈結資料處理流程及相關技術

目前開放資料與鏈結資料已有許多應用實例，本計畫將研究

鏈結資料相關技術、平台及資料處理流程。以下簡介現行鏈結資

料處理流程、相關技術及資料發布平台。鏈結開放資料階層架構

圖如下圖所示，其與鏈結資料不同處在於資料開放授權。鏈結開

放資料需依據 Open Knowledge Foundation 訂定的十一項條款，也

就是說若任何人皆可對一份資料或資料內容，自由地使用、重用

以及散播（符合姓名標示及相同方式分享的創用 CC 條 件下），

即可稱之為開放資料。

33

圖 19. 鏈結開放資料階層架構

d 規格化

區分與清理出可用以鏈結的資料，分辨出資料中的「概念」

成份，和這些概念的關係，並透過知識領域解釋這些概念。因此

需要進行 URI 設計。由於 URI 的設計與資料中的概念及其定義有

關，清楚且明確的定義可促進資料的分享，以供政府部門發布及

查詢鏈結開放資料。由於英國政府已對 URI 設計進行分析（Chief

Technology Officer Council，2010），本計畫擬研析其 URI 設計，

作為未來相關單位參考。

34

(5) 模式化

根據上一步驟所區分的概念念及其關係，建立知識本體

(Ontologies)。若欲以其他資料鏈結，需使用標準語彙，或已存在

的語彙，以清楚表達資料內涵。目前知識本體的定義多以 W3C

所定義的知識本體語言（OWL），以描述性邏輯（Description

Logic）來定義語意。格式上採用較為簡單的 Turtle 或 N3。而知

識本體的建立工具則以 Protégé 為最多人使用，如下圖所示。

圖20. Protégé建立知識本體示意圖

e 轉檔與連結

欲將資料鏈結至其他資料，需要清楚資料的脈絡關係，以找

到可以連結的資料。原始資料透過知識本體，需將資料轉化為

RDF 格式。常見的轉檔工具包含將 CSV 文件轉換為 RDF 的

XLWrap、RDF123 及 RDF extension of Google Refine 等。將儲存

於關聯式資料庫中的資料轉換為 RDF 三元組，以便在不影響原

有資料庫的情形下進行 SPARQL 查詢、瀏覽或是儲存成 RDF

格式，常使用的工具包含 D2R Server、ODEMapster 及 W3C

35

RDB2RDF WG-R2RML 等。D2R Server 運作概念圖，如下圖所

示。目前常使用的資料鏈結分析工具則包含：SILK

（silkframework.org）及 LIME（http：

//aksw.org/Projects/LIMES.html）。下圖為 SILK 運作畫面。

圖21. D2R Server運作概念（http：// http：//d2rq.org/d2r-server）

圖22. SILK軟體畫面（資料來源： silkframework.org/）

36

f 發布

提供介面存取 RDF 資料集及進行 SPARQL 查詢，可分成兩

種方式存取，一種為透過 RDBMS 進行轉換為 RDF 三元組，另

一種方式為直接存取 RDF 三元組資料集，概念如圖 23 所示。資

料轉為 RDF 後，需由三元組資料庫（triple stores）來儲存，因為

RDF 的查詢語言為 SPARQL，因此提供於網路上提供 SPARQL

來查詢和管理 RDF 的接口，又稱為 SPARQL 端點（endpoints），

目前已經有許多開源的工具可以使用，如 Jena、Virtuoso、Sesame、

4Store、OWLIM、和 BBN Parliament 等，而為方便 RDF 資料在

網頁上瀏覽，且可以直接透過網頁展示連結資料，目前也有數套

前端連結資料服務的工具可以使用，如 Pubby、 TalisPlatform、

Fuseki、和 D2RQ 等。Pubby 和 D2RQ 是二個受歡迎的前端鏈結

資料服務，但其資料處理與提供方式並不相同，D2RQ 強調資料

儲存於關連式資料庫中，透過 turtle 格式映對（mapping）編輯，

D2RQ 可以直接將關連式資料庫中之資料轉為 RDF，並直接顯示

於網頁上，而 Pubby 的後端則必須接上一個三位組資料庫來提供

資料。

圖23 RDF資料發布概念圖

37

g 三元組儲存庫

原始資料透過知識本體，將資料轉化為 RDF 格式，若是原始

資料為表格型態(spreadsheets)可以用 Google Refine 的 RDF 擴充

模組、XLWrap、RDF123、或 NOR2O 等工具，若資料是關連式

資料庫，則可以 D2RQ、 ODEMapster、或 W3C RDB2RDF WG 所

發展的 R2RML 等工具。而若是 XML 格式，則可以使用 GRDDL

或 ReDeFer。

資料轉為 RDF 後，必需由三位組資料庫(triple stores)來儲

存，將 RDF 資料處理後，以便提供查詢與管理，因為 RDF 的查

詢語言為 SPARQL，因此提供於網路上提供 SPARQL 來查詢和

管理 RDF 的接口，又稱為 SPARQL 端點(endpoints)，目前已經有

許多開源的工具可以使用，如 Jena、Virtuoso、Sesame、4Store、

OWLIM、和 BBN Parliament 等，而為方便 RDF 資料在網頁上瀏

覽，且可以直接透過網頁展示連結資料，目前也有數套前端連結

資料服務的工具可以使用，如 Pubby，TalisPlatform、Fuseki、和

D2RQ 等，值得注意的是 Pubby 和 D2RQ 是二個受歡迎的前端連

結資料服務，但其資料處理與提供方式並不相同，D2RQ 強調資

料儲存於關連式資料庫中，透過 turtle 格式映對(mapping)編輯，

D2RQ 可以直接將關連式資料庫中之資料轉為 RDF，並直接顯示

於網頁上，而 Pubby 的後端則必需接上一個三位組資料庫來提供

資料。

D2RQ Server 是依靠映對檔將資料庫中的資料轉化成為三元

組資料，進一步地可將三元組資料顯示於網頁中，使資料可以容

易用瀏覽器閱讀。為實現鏈結資料，本案將水災事件、水文觀測

值(雨量)、和水文環境(集水區)三個資料集，分別建立 SPARQL

Endpoint。

38

雖然 D2RQ 是一個簡單且易於建立的 SPARQL Endpoint 之

應用程式，但它的執行效能一 直最大的問題，Bizer and Schultz

(2008)進行 SPARQL Endpoint 的評估研究，其 SPARQL Endpoints

包含 Sesame、Virtuoso、Jena SDB、和 D2R Server，表 1 所示。

結果發現，當查詢結果較大時，D2R Server 幾乎無法處理，而以

效能而言，它表現也沒有其它 SPARQL Endpoint server 來的好。

表1： 利用執行50個查詢評估SPARQL Endpoints(單位：秒)

From Bizer and Schultz (2008)

然而依過去經驗，即便表現最好的 Virtuoso 在大量資料解析

時，亦有效能不彰的情形，因此本計畫擬採用 BrightStarDB 作為

本示範應用之 Triple Store。BrightStarDB 屬於 NonSQL 資料庫，

其具備解析 SPARQL Query 之能力(概念同 XMLDB)，本團隊將

開發 RESTful API 介面提供示範應用(Client 端)進行查詢呼叫，期

透過此種方式可有效解決效能及後續擴充性議題(如資安、SSL 憑

證、OAuth 驗證等)。

h SPARQL 查詢

SPARQL 為 RDF 的查詢語言，其設計的概念很像關連式資料

的查詢語言 SQL。為展現圖型式資料集和鏈結資料的好處，本案

使用聯合式(federated) SPARQL 查詢來建立前端的示範平台，如

圖 23 所示。

39

圖 24 Federated SPARQL Query 示意圖

RDF 是一個方向性的、標籤的圖型(graph)資料，向來表達在

網路中的資訊，SPARQL 可以用來表達跨不同資料來源的查詢，

其中資料需要是 RDF 或以 RDF 做為中繼的媒介，聯合式的

(Federated) SAPRQL Query 也是一個 W3C 所 倡議的標準1之

一。圖 22 為聯合式的 SPARQL 查詢之範例，其查詢跨過二個資

料集，或者說二個 SPARQL Endpoints，欲查詢紐約時報報導美國

總統的頭版文章，透過 DBpedia，可以找到美國總統，如圖 23 所

示，這些被找到的美國總統，則可以對映到紐約時報中總統，紐

約時報所用的語彙只是總統，並沒有說明是那一個總統，但因為

利用 sameAs 指向了 DBpedia，因此，機器知道在紐約時報找到

的這個 Barack Obama 總統，是美國總統，如圖 24 所示，聯合式

的(Federated) SAPRQL 可以一直利用這種方式查找下去，並找到

更多的總統，及其報導文章，如圖 25 所示。

1 https://www.w3.org/TR/sparql11-federated-query/ 12

40

圖25 聯合式的SPARQL查詢的範例

圖26 找出DBpedia中的美國總統

圖27 利用owl：sameAs對映所找的美國總統

41

圖28 對映出更多的美國總統

i 台泰水利防災資料來源

經研析近年東南亞遭到極端氣候變遷的衝擊面臨之課題主

要為水災、旱災及水質汙染三大課題，其中以水利治理問題最為

嚴重，蒐集東南亞各國潛在商機如下:

• 泰國，自 2011年下半年起投入超過 75億美元的十年水資源

管理計畫，以水利減防災為主軸。(訊息來源：中華民國對

外貿易發展協)

• 亞洲開發銀行，2016 年宣布與日本扶貧基金會合作，投資 100

萬美元於建立一個整合性綜合水資源管理模擬工具

(IWRM)，收集使用者測試不同的管理模式對於河川集水區

水文影響模擬結果及再利用開放資料進行水利防災分析。

• 越南，2018 年 1 月 3 日越南政府發佈關於 2018 年經濟社會

發展計畫的第 1 號決議中，提到加大對自然資源和環保管理

工作力度，有效開發和利用水資源，加強在跨境水資源尤其

是湄公河水資源有效開發、利用中的國際合作。（訊息來源：

越通社—VNA）

• 綜合歸納，以國際相關水利防災開放資料對本案推動之效益

高。

42

搭配主計畫推動 Asia open Data partnership (AODP)，對於未

來的國際資料集數量擴充規劃如下：

• 在現行台日農業活動/台泰水利災防所蒐集資料集基礎，同步

更新資料集內容外，並更新合作案的資料集源數量。

• 持續推廣新國家跨國資料應用合作，蒐集既有領域別資料集

源數量。

• 透過新增建立 1 個領域別跨國資料共通 API 格式標準及進行

資料互連驗證，並逐漸擴充新領域別資料集源數量。

• 配合新南向政策推動，擴展蒐集東協聯盟相關組織、機構、

或團體的開放資料，如 Open Development Initiative (ODI)支援

開放發展湄公河社群網站之 Open Development Mekong.的開

放資料源(https://opendevelopmentmekong.net/search/data/)。

目前本案採用水利防災開放資料說明如下:

(a) 台灣水利防災資料來源

台灣因國家災害防救科技中心早於民國 104 年起即依循國

際組織 OASIS 制定之 Common Alerting Protocol(CAP Alert)，正

規化災害事件通報之格式，相關資料亦以 Open Data 之形式開放

於災害示警公開資料平台。目前已篩選淹水、水災、水庫放流警

報等事件作為資料來源。

資料集名稱 資料來源 更新區間 國家

CAP災害事件 NCDR 即時更新 台

水庫基本資料 經濟部水利署 不定期更新 台

即時雨量資料 中央氣象局 即時更新 台

即時水位資料 經濟部水利署 即時更新 台

避難點為資料 水土保持局 不定時更新 台

43

圖 29 災害示警公開資料平台

(b) 泰國水利防災資料來源

因泰國目前並無完整的結構化水災資料來源，且對於水災相

關資訊尚未完成整合，故在事件選擇上將依據國際組織守護亞洲

(Sentinel Asia)之水災紀錄，並參考泰國 Early Warning

System(http://ews.dwr.go.th/ews/index.php)彙整出 2017/1、

2013/7、2011/8、2011/3、2010/10、2008/12、2008/11、2008/9、

2007/10 等水災事件。

資料集名稱 資料來源 更新區間 國家 筆數

降雨事件(含

嚴重等級)

水利部發展研究水文局

水監測和預警實驗室

2012-2016 泰 6798

雨量資料 泰國氣象局(Open Data

平台)

2012-2014 泰 120萬

水庫基本資料 泰國水資源與農業信息

研究所

不定時 泰 449

學校點位 泰國開放資料平台 不定時 泰 46206

44

圖 30 守護亞洲網站各國重大水災清單

由泰國官方水利部發展研究水文局水監測和預警實驗室所

監測之資訊網-Early Warning System，系統內共收錄共 6798 則降

雨事件，其資料內容依據嚴重程度可分為綠色、黃色、紅色三等

級，分別記錄了 2012 年至 2016 年間的降雨事件，本計畫將該網

站之資訊轉為結構化資料使用。

圖 31 泰國水災事件紀錄表

45

圖 32 泰國水災 Early Warning System

而針對災害淹水警示等相關資訊而言，泰國示警系統上所提

供之資訊尚未結合各地河川、水量觀測站等觀測資訊，因此本計

畫另由泰國開放資料網站上獲取 2012 年至 2014 年間 24 小時水

量資訊，此類資料由泰國官方氣象部門所提供，此段期間共累積

約 120 萬筆資料，而泰國開放資料網上已將該類資料結構化發布。

圖 33 泰國開放資料網-24 小時雨量資訊

46

圖 34 泰國 24 小時雨量資料 CSV 檔

以環境資料面而言，本計畫另外蒐集了泰國水庫及河川的資

訊，泰國水資源與農業信息研究所目前於 Thaiwater.net 網站上提

供泰國各地及各種規模下的水庫資訊，共記錄了 449 筆水庫資

訊，經本計畫資料結構化後使用。

圖 35 Thaiwater.net 水庫資訊

47

此外，配合情境應用需要，本計畫另針對泰國防救災地點資

訊進行蒐集，於泰國官方開放資料平台上取得泰國境內共 46206

筆學校用地資訊，為目前較為具體且具備實際點位之資料，此份

資訊由泰國教育部於 2015 年所統計提供，相關資料亦透過 D2R

機制轉換為鏈結資料格式。

圖 36 泰國開放資料網-學校用地資料

圖 37 泰國學校用地資料 CSV 檔

j 水利防災共通語意 API 導入企業經驗分享

水利防災共通語意 API 導入分享會議紀錄摘要

企業經此水利防災國際標準的語意資料互通知識本體協作導

入水利災防資料之共通語意 API 經驗，可有效地降地開發時

間及人力成說明如下:

48

過去資料分析花最多時間及人力成本是前期資料搜集、研究

標準化(含跨國共通語彙建立)與清理處理占整體專案執行流

程約 60%，而其他為系統開發及測試驗證約 40%。

經導入水利災防資料之共通語意 API 後，企業未來面對相關

跨國開發專案可降低 50%至 60% 於最花時間及人力成本的

資料處理以及資料結構定義標準化兩大步驟，同時系統開

發、連接及測試驗證也可降低約 10%作業時間及人力成本，

依據上述對企業數位經驗而言，可實質有效地降低類似專案

開發達 30%以上(60*50%+40*10%=34%)的時間與人力成

本。

(B) 擴增 1 個領域別跨國開放資料互通技術及規範(中文版)

(水利防災資料鏈結互通相關技術及規範中文版 1 份)

(1)完成擴增水利防災資料鏈結互通相關技術及規範中文版 1 份。

擬定水利防災資料鏈結互通相關技術及規範(水災事件知識本

體、水文觀測知識本體、水文環境知識本體)。

本計畫之台泰相互對映與連結水利防災知識本體之語彙報告與

水利防災資料鏈結互通相關技術及規範書，已經彙整於「跨國

開放資料平臺及互通規範書」，除了中文版之外，配合主計畫的

AODP的推動跨國開放資料互通政策，已經完成翻譯英文版本”

Transnational Open Data Interoperability Guideline”。

a 共同示警協定資料結構分析

共通示警協定(Common Alerting Protocol ,CAP)是結構化資

訊標準促進組織(Organization for the Advancement of Structured

Information Standards ,OASIS)公布的標準，是一種基於 XML 的數

據格式，用於在警報技術之間交換公共警告和緊急情況。

CAP 是緊急警報和公共警告的國際標準格式。 它專為“所

49

有危害”而設計，涉及天氣事件，地震，海嘯，火山，公共衛生，

停電和許多其他緊急情況。 CAP 還專為“全媒體”而設計，包

括從警報器到手機，傳真，廣播，電視和基於互聯網的各種數位

通信網絡的通信媒體，CAP 允許通過許多警告系統將警告消息一

致地傳播到許多應用程序，例如 Google Public Alerts 中。

CAP 使用者可以從許多來源接收標準化警報，並根據需要配

置其應用程序以處理和回應警報。CAP 數據結構向後相容現有的

警報格式，包括美國國家海洋和大氣管理局（National Oceanic and

Atmospheric Administration ,NOAA）氣象無線電中使用的特定區

域消息編碼（Specific Area Message Encoding ,SAME）和廣播緊

急警報系統以及無線緊急警報（Wireless Emergency Alerts ,WEA）

等新技術。

在 CAP 的架構中，每個 CAP 警報包括一個<alert>，它可能

包含一個或多個的<info>，其中每一個<info>可包括一個或多個

<area>與<resource>。

1. <alert>

<alert>提供了基本的訊息，包括訊息、目的、來源及狀

態，以及目前的訊息和連接到任何其他相關的訊息的唯一識

別代碼。

2. <info>

<info>描述預期或實際事件的緊急性，嚴重性和確定

性，以及提 供分類和文字描述。它也可能提供適當的應變

說明和其他各種細節的說明（影響時間，聯絡資訊….等）給

接收者。多個<info> 可以用來描述多個事件。

3. <resource>

<resource>提供<info>相關的數位資源，如圖像或影音檔

50

案。

4. <area>

<area>描述<info>相關的地理區域。

下圖為 CAP 之 UML 類別圖。

圖 38 CAP UML 類別圖

從上圖之 UML 可以看出相關之 Schema 主要是由一個 Alert

所組成，每個 Alert 包含著一到多個的 Info，Info 又可能包含著多

個區域 Area 以及相關之 Resource，對照著下圖實際相關資料可以

更清楚看出其相關架構對應關係。

51

圖 39 CAP Alert XML 資料

共通示警協定目前最新的版本是 OASIS 於 2010 年 7 月 1 日

發布的 1.2 版，在國際上鏈結資料較少為了因應水災事件所建立

之知識本體的情況下，因此以共通示警協定之國際標準做為訂定

知識本體之重要參考標準。

b 水文觀測資料標準結構分析

水文環境觀測部分採用OGC所制定之SensorThings API之資

料結構，共分為 Sensor(感測器&測站)、DataStream(傳輸資訊)、

Observation(觀測值)、Location(物理現象地點/optional)等四大主

題。本計畫將依此架構，透過 Protégé軟體進行資料本體論建置，

進而將台灣及泰國之水文觀測值作為 Instance 進行結構轉換後，

納入 Triple Store。

感測器物聯網應用程式界面(SensorThings API)是開放地理

空間協會 (Open Geospatial Consortium,OGC) 公布的標準，

SensorThings API 提供了一種開放的，支持地理空間的統一方式，

可通過 Web 互連物聯網（IoT）設備，數據和應用程序，解決了

物聯網的語法互操作性和語義互操作性問題。在高層次上，OGC

52

SensorThings API 提供兩個主要功能，每個功能由一個部件處理。

這兩部分是傳感( Sensing)部分和任務(Tasking)部分。傳感部分提

供了一種管理和檢索異構物聯網傳感器系統的觀測和詮釋資料

的標準方法。 任務部分計劃作為未來的工作活動，將作為

SensorThings API 的第 II 部分在單獨的文件中定義。

SensorThings API 補充了現有的物聯網網路協定，如 CoAP，

MQTT，HTTP，LowPAN。OGC SensorThings API 可用以解決不

同物聯網系統使用和理解交換信息的功能。作為 OGC 標準，

SensorThings API 還可以輕鬆整合到現有的空間數據基礎架構或

地理資訊系統中。

SensorThings API 的基礎是對物聯網系統中的實體（entities）

在現實世界中的相互關係進行模型化。這些實體之間的自然關係

使得任何垂直產業中的物聯網傳感器設備都可被模型化。比如，

一個物聯網設備（device）或者一個物聯網系統（system）可模型

化為一個物體（Thing），一個物體（Thing）既含有位置（Location），

也含有一個或多個數據流（ Datastreams ）。每個數據流

（Datastream）都是通過一個傳感器（Sensor）觀測一個觀測屬性

（ObservedProperty）而獲得的，且這個傳感器（Sensor）可能存

在多個觀測（Observations）。傳感器（Sensor）觀測（Observation）

的是一個特定的被觀測物（FeatureOfInterest）。綜合以上，這些

相互關系就可靈活且標準化地描述和模擬各種傳感系統，

SensorThings 借助這些相互關系從而實現了為任何組織的異構設

備提供了單數據交換的功能。

下圖為 OGC SensorThings API 的 UML 數據模型，其中定義

了不同的實體以及他們的屬性，同時展示了不同實體之間的關

53

係。

圖 40 感測器物聯網應用程式界面的 UML 類別圖

感測器物聯網應用程式界面目前最新的版本是 OGC於 2016

年 7 月 26 日發布的 Part I – Sensing 1.0 版，同時 Part II - Tasking

Core 則於 2018 年 2 月 20 日，進行公開意見徵求階段。

c 水文環境資料標準結構分析

WaterML 是 開 放 地 理 空 間 協 會 ( Open Geospatial

Consortium,OGC)公布的標準，用於表示水觀測數據的標準資訊模

型，旨在允許跨資訊系統交換這些資料集。 通過使用現有的 OGC

標準，WaterML 為可互操作的交換格式，可以重複使用以滿足一

系列交換要求。

WaterML 目前最新的版本是 OGC 於 2014 年 2 月 24 日發布

的 2.0 版。WaterML 所建模的水資源周期如下圖：

54

圖 41 水資源周期圖

WaterML 共分為四部分，分別是時間序列(Timeseries )、評級

與測量部分 (Ratings, Gaugings and Sections)、表面水文特徵

（ HY_Features ） - 概 念 模 型 、 地 下 水 資 源 標 記 語 言

(GroundWaterML ) WaterML 的 UML 類別圖如下：

圖 42 WaterML 的 UML 類別圖

55

d 可延伸觀測知識本體(The Extensible Observation Ontology，

OBOE)

生態學為由多學門所組成的學科，使生態分析所提供的資訊

範圍非常廣泛，如地理學、海洋學、水文學等，也因此在進行綜

合性分析來加以研究生態問題時，不同數據來源的需求也相對增

加，但基於目前相關數據的分析方法效率較低，且生態學中因資

料異質性的問題，在測量生態學相關變量時缺乏較為統一的標

準，生態詮釋資料語言(Ecological Metadata Language，EML)即為

用於保存關於生態數據集的詮釋資料，為國際上重要生態研究使

用之生態詮釋語言，EML 所採用的語法參照了國際上 metadata

標 準 的 技 術 ， 在 基 於 Geographic Information Standard

（ISO19115）、Geography Mark Language（GML）等所訂定的規

則下，美國加州大學國家生態學分析與綜合研究中心 (The

National Center for Ecological Analysis and Synthesis，NCEAS)所提

出的 SEEK(Science Environment for Ecological Knowledge)生態資

訊計畫中，以觀察與量測為基礎的知識本體，透過 OWL(Web

Ontology Language) 建 立 一 框 架 式 知 識 本 體 (framework

ontology)，即為可延伸觀測知識本體(The Extensible Observation

Ontology，OBOE)，簡稱為 OBOE(Madin et al., 2007)。

而 OBOE 知識本體主要目標為描述觀測資料集的語意，由觀

察的對象以及測量的特徵、標準作為知識本體的節點，並制定了

一種通過使用擴展點來組織域特定本體的結構化方法，OBOE 的

主要類別允許根據特定術語定義本體，並將現有類別擴展相互關

聯，因此，OBOE 可以作為定義新領域本體以及互操作和關聯現

有領域的框架，多數的應用將會基於擴展點來向外延伸，並可根

56

據研究所需做細部定義。

OBOE 以創建特定研究領域的實體和特徵為主要概念，使

其廣泛適用和高度可延伸，OBOE 由測量特徵、測量標準等七大

類別及其所對應的屬性所組成，分別為 Observation(測量實體的

類別)、Entity(測量實體)、Measurement(測量事件)、Characteristic(測

量實體的特徵)、Value(測量數值)、Standard(單位)、Protocol(架

構)，如圖 43 所示。

圖 43 OBOE 知識本體架構

(a) 環境和生態數據整合管理

OBOE 知識本體以觀測量為主要定義資訊，可針對生態學上

的數據做語意的轉化，而水文觀測資料則同屬於生態管理之範

疇，(Patton et al., 2014) SemantEco 的研究中將生態資訊與水源資

訊應用鏈結資料的技術做結合，原始資料包含了美國地質調查所

( United States Geological Survey，USGS)水體數據、美國國家環

境保護局（Environmental Protection Agency，EPA）環境標準及其

57

他相關生態資料，透過以 OBOE 為主的本體，建立了一生態水體

模型，如下圖 44，將不同來源的資訊結合，此研究中針對各種來

源的資料進行了模組化，為資源管理者提供決策支援系統，並使

資訊應用更加廣泛，模組化的體系結構允許數據資料的延伸。

圖 44 一生態水體模型

(C) 擴建 1 個領域別共通語彙基盤

a 完成擴建台泰相互對映與連結水利防災知識本體之語彙

針對國際標準 CAP Alert、SensorThings API、WaterML 等標

準進行核心語彙之建立，此外並參考 G. Fattoruso 及 A. Agresta 的

研究參考 Flood Glossary 的語彙進行制定，水利防災基本語彙對

應規劃示意。相關技術說明簡述如下:

58

核心詞彙是資料交換和整合重要的基礎，在資料日益增長

下，為了資料整合，以提供更好的公共服務，各國政府都紛紛建

立核心詞彙。美國國家資訊交換模型(National Information

Exchange Model) 於 2005 年由美國司法部和國土安全部開始發

展。隨後，逐漸整合聯邦、州、地方、部落政府，以及私部門以

發展國家級資訊交換模型，並部署組織結構中以便資料治理。至

2010 年，陸續有更多的美國政府部門，包含美國健康與人類服務

部、國防部、交通部、農業部等，隨著部會加入已經有 7 次版本

更新，目前最新的是 NIEM 4.0。順應電子化政府和開放資料的發

展下，歐盟政府為了降低各國之資料交換成本，進一步達成資料

可以無縫地交換，發展出歐盟電子化政府核心語彙(E-Government

Core Vocabulary)，並將核心語彙視為資料的重要基礎架構，由於

目前尚無針對水災事件、水文環境管理上較為成熟的通用語彙，

本計畫將針對國際標準 CAP Alert、OBOE 等標準進行核心語彙之

建立，此外並參考 G. Fattoruso 及 A. Agresta 的研究參考 Flood

Glossary 的語彙進行制定，水利防災知識本體語彙共分水災事

件、水文環境、水文觀測三個部分，共定義 79 個水利防災知識

本體語彙。

對於國際資料的語言格式及資料的統一彙整技術面，目前採

用國際標準化組織 ISO 639語言代碼標準

(https://zh.wikipedia.org/wiki/ISO_639-1)如中文碼：zh；

泰文碼：Th；英文碼：en，作為跨國領域別國際資料的語言統一

彙整基礎。

對於國際資料的語言資料的統一彙整技術面，目前採用各領

域別國際標準，訂定跨國間共同語彙，開發跨國資料共通應用

59

API，如水利災防領域，災害事件資料採用共通示警協定(Common

Alerting Protocol ,CAP)；水文環境觀測領域，感測資料採用

OGC SensorThings API；水文環境領域，採用 OBOE 或 OGC

WaterML。農業活動領域，採用日本農業活動本體 (AAO)。搭配

跨國各領域資料混搭應用案例推廣跨國資料共通應用 API之跨國

組織、機構、或團體使用數目及使用次數，逐漸充實完善跨國各

領域資料語彙內容。示意表如下所示。

(a) 水災事件

設計完成之水災事件知識本體語彙表如下表：

語文 中文 英文 泰文(擴充案例)

分類 核心語彙 Vocabulary ศพท

Alert

警戒 Alert เตอนภย

訊息編號 MessageID ขาวสาร

發布者編號 SenderID ผสง

發布時間 Sent Date ปลอย เวลา

訊息狀態 Message Status สถานะขอความ

訊息類型 Message Type สถานะขอความ

來源 Source ประเภทขอความ

範圍 Scope ขอบเขต

限制 Restriction ขอ จ ากด

地點 Address สถานท

處理狀態 Handling สถานะการประมวลผล

備註 Note ค าพด

參考編號 ReferenceID หมายเลขอางอง

事件編號 IncidentID หมายเลขเหตการณ

Info

資訊 Info ขอมล

語言 Language ภาษา

事件分類 Event Category การจดหมวดหมเหตการณ

事件類型 Event Type ประเภทเหตการณ

回應類型 Response Type การตอบสนอง ชนด

急迫性 Urgency การเรงรบ

嚴重性 Severity ความรนแรง

確定性 Certainty ความเชอมน

發布對象 Audience ปลอย วตถ

60

事件編號 Event Code เหตการณ จ านวน

生效時間 Effective Date วนทมผล

設定時間 Onset Date ตงเวลา

逾期時間 Expiration Date วนหมดอาย

發布人姓名 Sender Name ส านกพมพ

標題 Headline พาดหว

事件描述 Event Description เหตการณ ลกษณะ

指示 Instruction คมอ

資訊連結 InformationURL ลงคขอมล

聯繫資訊 Contact Info ขอมลการตดตอ

參數 Parameter พารามเตอร

Area

區域 Area ภมภาค

區域描述 Area Description ค าอธบายพนท

區域多邊形 Area Polygon รปหลายเหลยมของพนท

區域範圍 Area Circle พนทวงกลม

地理編碼 Area Geocode พกดทางภมศาสตร

高度 Altitude ความสง

上升限度 Ceiling ขด จ ากด บน

Reso

urce

資源 Resource ทรพยากร

描述 Description การเลาเร อง

媒體類型 MIME Type ประเภทสอ

檔案大小 File Size ขนาดไฟล

連結 URI ลงค

差異連結 Deferenced URI ลงคธรกรรม

摘要資訊 Digest ขอมลสรป

(b) 水文環境

設計完成之水文環境知識本體語彙表如下表：

語文 中文 英文 泰文(擴充案例)

分類 核心語彙 Vocabulary ศพท

Entity 測站編號 Station ID หมายเลขสถาน

測站名稱 Station Name ชอสถาน

Observation

水庫編號 Reservoir ID จ านวนอางเกบน า

水庫名稱 Reservoir Name ชออางเกบน า

河川編號 River ID หมายเลขแมน า

河川名稱 River Name ชอแมน า

觀測採集 Observation Collection การสงเกตการณ

經度 longitude ลองจจด

61

緯度 latitude ละตจด

(c) 水文觀測

設計完成之水文觀測知識本體語彙表如下表：

語文 中文 英文 泰文(擴充案例)

分類 核心語彙 Vocabulary ศพท

Characteristic

雨量 Rainfall ปรมาณน าฝน

水量等級 Water Level ระดบน า

一級警戒 Alert Level 1 แจงเตอนระดบแรก

二級警戒 Alert Level 2 การแจงเตอนรอง

三級警戒 Alert Level 3 การแจงเตอนระดบทสาม

識別特徵 Identifying

Characteristic การระบลกษณะ

測量特徵 Measured Characteristic ลกษณะทวดได

基本限制 Base Characteristic

Qualifier ลกษณะพนฐานรอบคดเลอก

複合限制 Composite

Characteristic Qualifier

ลกษณะเฉพาะของคอมโพสตร

อบคดเลอก

Measurement

測量事件 Measurement การวด

測量數值 Measurement Value คาการวด

測量類型 Measurement Type ประเภทการวด

Standard

分類標準 Categorical Standard มาตรฐานหมวดหม

指數 Index ดชน

基本單位 Base Unit หนวยฐาน

複合單位 Composite Unit ประกอบดวยหนวย

衍生單位 Derived Unit หนวยทไดรบ

前綴單位 Prefixed Unit น าหนาหนวย

單位轉換 Unit Conversion การแปลงหนวย

由於目前防災領域別語彙以台泰跨國水利防災資料混搭應

用為基礎，未來伴隨推廣過程，結合各跨國防災資料混搭應用協

作期間擴充實際語彙需求，將逐漸加強充實防災領域語彙內容。

62

b 詞彙與知識本體的對應

知識本體(ontologies)為知識分享的橋樑，因知識本體為使知

識清晰明確的方法，所以知識本體經常被用於消除不同資訊來源

的語意分歧，許多研究指出知識本體趨使的(Ontology-driven) 方

法可以使異質且分散的資料整合工作更為容易 (Bishr，1998；

Fonseca and Egenhofer，1999； Fonseca et al.，2002； Kolas et al.，

2005) 。 在大量異質資料的知識發掘中，知識本體並扮演重要的

角色，因為知識本體可以使敘釋資料(metadata)架構和控制詞彙

(controlled vocabularies)模式化 (Lacasta，et al.，2007)。為了地理

資料於空間資料基礎設施中達成語意層級的互動，知識本體常被

使用來正規地表現資料的概念模式，而使資料在瀏覽、存取和處

理過程中不會有資訊語意上的誤差 (Lutz and Kolas，2007)。因

外，為整合地理資訊服務，知識本體被使用在建立一個共同語彙

和可分享的服務敘述之架構，使得地理資訊服務得以一連串的自

動處理 (Lemmens et al.，2006)。

本體映對(Ontology mapping)顧名思義的是將一本體中的一

個元素(component)最多映對到另一個本體中的一個元素，本體映

對必須考量到映對規則(mapping rules)的建立，映對規則是指一本

體中一個元素對應到另一本體中的一個元素的關係，或匹配的演

算邏輯，而本體中的元素是指類別(classes)、實例(individuals)和

屬性(properties)或公式(formulas)(Euzenat and Shvaiko，2007)。而

本體映對常被使用在地理資訊整合，Kokla 和 Kavouras (2001) 在

正規化地理文本(context)後，利用本體映對技術將已存在的地理

本體整合到相關的上位的知識本體(top-level ontologies)，這個處

理方式是利用交叉表(cross table)來比較不同的地理概念後，再將

相似的地理概念整合在一起。Kavouras 等人(2005)提出一個由地

63

理類別，如土地利用分類的定義中比較語意屬性和關係的方法，

這個方法提供一個對於不同地理本體的語意比較方法。

Stoimenov 等人 (2006) 則利用語意中介架構(semantic mediator

architecture)發展混合的本體(hybrid ontology)以映對不同資訊社

群所使用的語彙的本體，同時也將不同社群的本體映對到高階本

體中。決定不同本體中的各個元素異同是本體映對中重要的步

驟，許多研究多致力於語意相似的量測，以決定不同地理資訊的

整合，Rodriguez 等人(1999) 發展匹配距離相似度量測

(Matching-Distance Similarity Measure，MDSM) 來決定空間實體

的語意相似度，接著，Rodriguez 和 Egenhofer (2004) 改良 MDSM

並應用於人對於空間實體的判別之相似程度。Schwering和Raubal

(2005)提出一個語意相似度的量測方法，用來決定自然語言中不

同地理概念的空間關係。

舉例而言，圖 37 有二個知識本體描述了 228 和平紀念日，

利用自然語言處理，可以找出，com：City 和 app：City 是一樣的

類別，且 com：Holiday 和 app：Holiday 也一樣的類別，這二組

一樣的類別可以利用 owl：equivalentClass 連結，而 com：Holiday

其實也就是 app：Event 的 com：Holiday 或 app：Holiday 的上位

類別，因此 com：Holiday 可以是 app：Holiday 的 rdfs：subClassOf。

此外，「台北」和「Taipei」二個實例(instance)是一樣的，「228 和

平紀念日」和「228 Memorial Day」二個實例是一樣的。了解二

個知識本體之間的類別和實例的相似的對映關係後，二個知識本

體即可整併，本計畫亦將採用相似的概念進行實作，針對台灣及

泰國在水利防災相關資料描述上建立本體對映關係。

64

圖 45 本體映對概念

(D) 擴增 DCAT-AP Data Model

已 2018/08/30 完成開放資料整合平台擴增 DCAT-AP Data

Model，並提出開放資料整合平台擴增 DCAT-AP Data Model

報告 1 份，相關擴增 DCAT-AP 相關系統設計項目如下簡述：

a 資料模型說明及比較

(a) 資料目錄字彙(Data Catalog Vocabulary , DCAT)

DCAT 是 W3C 於 2014 年發布的 RDF 字彙標準，設計

用來進行網路上資料目錄間的互通 ，廣泛受到美國、歐

盟及開放資料平台如 CKAN 的支援，目前開放資料統整

平台採用。

DCAT 定義了三個主要的類別

• dcat:Catalog 代表資料目錄

• dcat:Dataset 代表資料目錄中的一個資料集

65

• dcat:Distribution 代表一個資料集的可流通版本，如可

下載的檔案、RSS feed 或 web service。

DCAT 使 用 SKOS (Simple Knowledge Organization

System)來處理資料集主題的議題。

資料目錄字彙命名空間如下

(b) 資料目錄字彙一致性

I. 如果資料目錄符合 DCAT：

• 此資料目錄由資料集和流通版本組成

• 使用 RDF 來描述目錄、資料集、流通版本

• 詮釋資料由 DCAT 字彙描述

• 使用 DCAT 字彙時，語義需與規範中描述的一致

• DCAT 相容目錄可新增非 DCAT 的詮釋資料

II. 資料目錄字彙配置檔是為 DCAT 增加額外約束的資料

目錄的規範。 符合配置文件的資料目錄也符合 DCAT。

配置文件中的其他限制可能包括：

• 必須欄位的最少集合

• 新增不屬於 DCAT 的類別或屬性

• 使用控制字彙或 URI 來做為屬性的可接受值

• RDF 特定的存取機制

66

歐盟的 DCAT Application Profile ( DCAT-AP )規範即是

DCAT Profile 的範例。

(c) 資料目錄字彙的 UML 類別圖如下:

圖 46 DCAT的 UML類別圖

除了 dcat:Catalog、dcat:Dataset 及 dcat:Distribution 這三個

主要的類別之外，另外還有四個輔助性的類別：

• dcat:CatalogRecord 代表資料目錄中的一筆資料，

用來描述資料目錄中的一個資料集

• skos:Concept 代表資料目錄中的主題資訊

• skos:ConceptScheme 代表主題資訊的知識組織系統

( Knowledge Organization System, KOS)

• foaf:Agent 代理人，代表資料目錄或資料集的代理

人，可以是人或組織

DCAT 中對主題式資料集的支援，共呈現在兩種層級，在

dcat:Catalog（資料目錄）中可以使用 dcat:themeTaxonomy

67

欄位屬性來表示資料目錄所屬的主題；在 dcat:Dataset（資

料集）中可以使用 dcat:theme 欄位屬性來表示資料集所屬

的主題。RDF 範例如下：

:dataset-001 dcat:theme :accountability .

:accountability

• a skos:Concept ;

• skos:inScheme :themes ;

• skos:prefLabel "Accountability" ;

(d) 資料目錄字彙(DCAT)模型的類別 URI、描述和參考

(e) 資料目錄字彙(DCAT)示例-公車站資料集

68

(f) 常用受控詞彙

I. 使用語言 ( dct:language )

• 主要使用 ISO 639 系列標準

• 另外繁體中文可用

http://id.loc.gov/vocabulary/ISO639-3/och 表示，

• 簡體中文可用

http://id.loc.gov/vocabulary/ISO639-3/zho 表示

II. 更新頻率 (dct:accrualPeriodicity )

• 主要使用 SDMX(Statistical Data and Metadata

eXchange)系列標準

69

(g) 資料目錄字彙-應用配置檔(Data Catalog Vocabulary –

Application Profile)

歐盟資料目錄字彙應用配置檔(Data Catalog

Vocabulary – Application Profile, DCAT-AP) 是以 W3C的

DCAT標準為基本進行擴充，專門用來描述歐洲公部門資

料集的詮釋資料標準。

DCAT-AP重用了 DCAT定義的字彙標準，增加為了歐

洲公部門應用而導入的特殊限制，例如將 DCAT的類別和

屬性分為「必要(Mandatory)」、「推薦(Recommended)」、「選

擇(Optional)」三種層級，以及為屬性的值導入了控制字

彙(Controlled Vocabularies)

I. 在 DCAT-AP 配置文件中使用的術語

DCAT-AP應用配置檔是重新使用來自一個或多個

基本標準的術語的規範，通過識別要用於特定應用程

序的必要性，推薦和選擇元素以及對要使用的受控詞

彙表的建議來增加更多的特異性。

在以下部分中，類別和屬性分為標題“必要”，

“推薦”和“選擇”。這些術語具有以下含義：

70

• 必要類別:資料接收器必須能夠處理有關類別的實例

的資訊;資料發送方必須提供有關該類別的實例的

資訊。

• 推薦類別:資料的發送者應該提供有關類別的實例的

資訊;資料發送方必須提供有關該類別的實例的資

訊 (如果有這些資訊);資料接收器必須能夠處理有

關類別的實例的資訊。

• 選擇類別:接收方必須能夠處理有關類別的實例的資

訊;寄件者可以提供資訊，但沒有義務這樣做。

• 必要屬性:接收方必須能夠處理該屬性的資訊;寄件者

必須提供該屬性的資訊。

• 推薦的屬性:接收方必須能夠處理該屬性的資訊;寄件

者應提供該屬性的資訊 (如果可用)。

• 選擇屬性:接收方必須能夠處理該屬性的資訊;寄件者

可以提供該屬性的資訊，但沒有義務這樣做。

DCAT-AP應用配置檔重用各種現有規範中的術語，所指

定的類別和屬性取自以下命名空間：

71

II. DCAT-AP 詮釋資料的提供者一致性

DCAT-AP詮釋資料的提供者稱 DCAT-AP Provider，

需要符合以下條件

• 提供目錄(Catalog)的必要(Mandatory)屬性詮釋資料

• 提供資料集(Dataset)的必要(Mandatory)屬性詮釋資料

• 若使用可流通版本(Distribution)類別時，提供可流通

版本的必要(Mandatory)屬性詮釋資料，可流通版本

為推薦(Recommended)類別

• 提供代理人(Agent)的必要(Mandatory)屬性詮釋資料

• 若使用目錄記錄(CatalogRecord)類別時，提供目錄記

錄的必要(Mandatory)屬性詮釋資料，可流通版本為

選擇(Option)類別

• 於 DCAT-AP 1.1 所列出，需要使用的控制字彙，

DCAT-AP Provider 都需要使用

III. DCAT-AP 詮釋資料的接收者一致性

DCAT-AP詮釋資料的接收者稱 DCAT-AP Receiver，

需要符合以下條件

• 需要能夠處理 DCAT-AP 1.1 規範中所有的類別，包

含必要、推薦及選擇類別

• 需要能夠處理 DCAT-AP 1.1 規範中所有的屬性，包

含必要、推薦及選擇屬性

• 需要能夠處理 DCAT-AP 1.1 規範中所有的控制字彙

IV. 類別和屬性的快速參考表

72

(h) CAKN 資料模型

CKAN資料模型的設計理念是以極簡的方式進行以資料

集(Dataset)為核心的必要設計，再把其它各種可能的擴充

方式留給各國開放資料的開發團隊，因為這種極簡的理

念，使得 CKAN在世界各地的官方及民間組織的資料網站被

廣泛的使用，如英國的 data.gov.uk以及歐盟的

73

publicdata.eu、巴西、荷蘭、日本政府入口網站均採用，

而美國開放資料網站 data.gov於 2013年 5月也正式採用

CKAN資料管理平臺。

也因為其極簡的理念，核心的資料集(Dataset)也只定

義名稱(name)、標題(title)、版本(version)、網址(url)、

作者(author)、授權條款(license)、附註(notes)七個詮

釋資料欄位，其餘的詮釋資料，都以 extra欄位形式進行

擴充。

資源(Resource)是資料集的一個實體可流通的版本，

如 CSV檔、XML檔或 JSON檔，相當於 DCAT字彙的

Distribution，也只定義網址(url)、格式(format)、描述

(description)、雜湊(hash) 四個詮釋資料欄位，其餘的

詮釋資料再由應用開發者自行擴充。

標籤(Tag)只有名稱(name)一個詮釋資料欄位，作用相

當於資料集的關鍵字，群組(Group)是用來組織資料集之

用，可以視為是資料集的分類(Category)，定義名稱

(name)、標題(title)、描述(description) 三個詮釋資料

欄位。

CKAN的資料模型如下圖所示：

74

(i) CAKN 與 DCAT-AP 資料模型比較

在進行 CKAN平台擴充 DCAT-AP Data Model時，首先

要做的工作，就是比對 CKAN、DCAT、DCAT-AP這三個資料

模型的異同，試著產生 CKAN與 DCAT-AP兩個模型間的雙向

轉換對照表。

CKAN與 DCAT-AP的差異主要表示在以下兩方面：

I. CKAN 沒有目錄(Catalog)的概念，目錄在 DCAT-AP

是用來組織與收集資料集之用，CKAN 是以組織

(Organization)來組織與收集資料，而組織在 DCAT-AP

是屬於發行者這個詮釋資料欄位。

II. 在 DCAT-AP 中，授權條款(license)存在於目錄這個層

級，也就是同一目錄使用相同的授權條款，如果同一

目錄需要引用不同的授權條款時，則可以在可流通版

本(Distribution)這個層級設定新的授權條款，在資料

集這個層級，是沒有授權條款這個欄位的。而 CKAN

則正好相反，授權條款則存在於資料集這個層級。

也因為 CKAN與 DCAT-AP這兩項主要的差異，CKAN與

DCAT-AP兩個模型間的雙向轉換無法做到 100％的轉換相

容，這個議題需要等到 W3C與 ODI這兩個模型的設計組織

共同討論，在新的資料模型版本尋求解決方案。

b 需求說明

(a) 開發級需求

I. 使用 ckan plugin 開發，使用 PCA(PyUtilib Component

Architecture)架構開發，如圖 54

75

圖 47 PCA 架構圖

II. 語系可擴充性：資料模型的詮釋資料欄位具多語系支援

能力，可擴充至中/英文以外的語系。

III. 資料模型可擴充性：當參考的 CKAN 與 DCAT-AP 資料

模型出現更新的版本時，具擴充至新版本的能力。

(b) 業務級需求

I. DCAT-AP 剖析器(Parser)：DCAT-AP 剖析器可以剖析符

合 DCAT-AP 規範的 RDF 檔案，取出資料集詮釋資料，

可使用在命令列程式中。

II. DCAT-AP 序列化器(Serializer)：DCAT-AP 序列化器可

以將 CKAN 入口網站中資料集的詮釋資料，輸出為符

合DCAT-AP規範的RDF檔案，可使用在命令列程式中。

III. RDF DCAT 輪廓(Pofile)類別：DCAT 輪廓(Pofile)類別

可以在符合 DCAT-AP 規範的情形下，進行客製化設

定，例如可以依國家別、應用別（統計、地理）進行設

定，此為內部類別，為 DCAT-AP 剖析器及 DCAT-AP

序列化器呼叫使用。

76

IV. RDF 資料收集器(Data Harvester)：RDF 資料收集器

(Data Harvester)可以收集外部符合 DCAT-AP 規範的

RDF 檔案，匯入 CKAN 入口網站中，可使用在命令列

程式或 CKAN 外掛(plugin)中。

V. DCAT-AP 擴充資料集：CKAN 資料集的詮釋資料欄位

擴充至相容 DCAT-AP 1.1，可新增、修改、瀏覽資料集。

VI. DCAT-AP 擴充資源：CKAN 資源的詮釋資料欄位擴充

至相容 DCAT-AP 1.1，可新增、修改、瀏覽資源。

VII. RDF DCAT-AP 服務端點：CKAN 資料集可匯出 RDF

DCAT-AP 格式的詮釋資料。

(c) 用戶級需求

I. ckan plugin：提供 DCAT-AP plugin 供 CKAN 入口網站

使用者使用。

II. 命令列工具：提供 DCAT-AP 命令列工具供應用開發者

使用。

III. API 界面：提供 DCAT-AP API 界面供應用開發者使用。

77

c 使用情境及功能說明

(a) DCAT-AP 擴充資料集情境

I. 具有編輯權限的使用者登入後，可以新增、修改詮釋資料

欄位擴充至相容 DCAT-AP 1.1 的 CKAN 資料集。

如下圖的 Theme/subject是DCAT-AP 1.1的分類(Category)

欄位，可進行編輯。

II. 不具有編輯權限的一般使用者，可以瀏覽詮釋資料欄位

擴充至相容 DCAT-AP 1.1 的 CKAN 資料集。

如下圖的 Theme/subject是DCAT-AP 1.1的分類(Category)

欄位，可瀏覽到新擴充的欄位。

78

(b) DCAT-AP 擴充資源情境

I. 具有編輯權限的使用者登入後，可以新增、修改詮釋資料

欄位擴充至相容 DCAT-AP 1.1 的 CKAN 資源。

如下圖的 Status 是 DCAT-AP 1.1 的狀態(Status)欄位，可

進行編輯。

79

I. 不具有編輯權限的一般使用者，可以瀏覽詮釋資料欄位擴

充至相容 DCAT-AP 1.1 的 CKAN 資源。

如下圖的 Status 是 DCAT-AP 1.1 的狀態(Status)欄位，可

瀏覽到新擴充的欄位。

(c) RDF DCAT-AP 服務端點情境

使用者可以使用以下的方法呼叫 RDF DCAT-AP 服務端點。

https://{ckan-instance-host}/dataset/{dataset-id}.{format}

其中 format 可以接受的格式及說明如下表：

副檔名 格式 媒體型式

xml RDF/XML application/rdf+xml

ttl Turtle text/turtle

n3 Notation3 text/n3

jsonld JSON-LD application/ld+json

80

d 架構設計

(a) PCA 架構設計

擴增 DCAT-AP Data Model 工具為一 ckan plugin 模組，使

用 PCA(PyUtilib Component Architecture)架構開發，PCA 在軟

體工程上屬於以元件為基礎 (Component Based Software

Engineering ，CBSE)的軟體開發架構，PCA 的基本概念有：

I. plugin

Plugin 為實作特定介面(interface)的類別(class)，特定介面包

含一組相關的方法(method)，因此 plugin 可被視為一個元件

(component)。

II. service

Service 是一個 plugin 類別的實例(instance)，因此 service 是

元件實例。

III. interface

Interface 類別定義了一組相關的方法(method)，可被 plugin

類別實作並使用。

IV. extension points

一個軟體系統或軟體元件可以定義 extension points，讓其它

的元件可以加入該軟體系統並擴充新功能，一個 extension

point 是由特定的 interface 所定義。也就是說一個新的服務，

可以藉由實作特定的介面，將新功能透過 extension point 加

入原有的軟體系統或軟體元件，籍由這個機制提供了軟體系

統使用上的彈性、擴充性以及模組化功能。

81

圖 48 CKAN 的 PCA plugin 架構

CKAN 的 PCA plugin 架構共定義了 4 種類型的 plugin 讓開發

人員進行擴充，如下所述：

I. routes

Routes 定義了 CKAN URL 路徑和 Views 之間的連接，接收

requests 並回傳 responses。

II. Views

Views 定義了網頁如何呈現的 HTML 範本，Views 會讀取以

Jinja 2 範本語言撰寫的 HTML 範本，再加以呈現。

III. Logic

Logic 定義了 CKAN 的功能處理部分，如 API 呼叫、認證功

能、背景執行程式與商業邏輯等。

IV. Models

Models 定義了 CKAN 與資料庫連接的資料模型部分，如資

料表單、搜尋引擎、系統管理資料庫、資料集資料庫等。

82

(b) CKAN 與 DCAT-AP 雙向轉換對照表設計

I. DCAT-AP 類別：Dataset

DCAT-AP 屬性 CKAN 欄位 欄位型別 附註

dct:title title text

dct:description notes text

dcat:keyword tags Text

dcat:theme extra:theme Text

dct:identifier extra:identifier Text

adms:identifier extra:alternate

_identifier

Text

dct:issued extra:issued Text

dct:modified extra:modified text

owl:versionInfo version text

dct:language extra:language text

dcat:landingPage url text

dct:accrual

Periodicity extra:frequency

text

dct:conformsTo extra:conforms

_to

text

dct:accessRights extra:access

_rights

text

foaf:page extra:document

ation

text

dct:provenance extra:provenan

ce

text

dct:type extra:dcat_type text

dct:hasVersion extra:has

_version

text

dct:source extra:source text

dct:spatial extra:spatial_uri text

dct:temporal

extra:temporal_start

+

extra:temporal_end

text

dct:publisher extra:publisher_uri text

dcat:distribution resources text

II. DCAT-AP 類別：Distribution

DCAT-AP 屬性 CKAN 欄位 欄位型別 附註

dct:title resource:name text

dcat:accessURL resource:access_url text

dcat:downloadURL resource:download text

83

_url

dct:description resource:description text

dcat:mediaType resource:mimetype text

dct:format resource:format text

dct:license resource:license text

adms:status resource:status text

dcat:byteSize resource:size text

spdx:algorithm resource:hash

_algorithm

text

(c) 資料庫資料表 JSON 設計

{

"scheming_version": 1,

"dataset_type": "dataset",

"about": "A reimplementation of the default CKAN dataset

schema",

"about_url": "http://github.com/ckan/ckanext-scheming",

"dataset_fields": [

{

"field_name": "title",

"label": "Title",

"preset": "title",

"form_placeholder": "eg. A descriptive title"

},

{

"field_name": "name",

"label": "URL",

"preset": "dataset_slug",

"form_placeholder": "eg. my-dataset"

},

{

"field_name": "notes",

"label": "Description",

"form_snippet": "markdown.html",

"form_placeholder": "eg. Some useful notes about the

data"

},

{

"field_name": "tag_string",

"label": "Tags",

"preset": "tag_string_autocomplete",

"form_placeholder": "eg. economy, mental health,

government"

84

},

{

"field_name": "license_id",

"label": "License",

"form_snippet": "license.html",

"help_text": "License definitions and additional

information can be found at http://opendefinition.org/"

},

{

"field_name": "owner_org",

"label": "Organization",

"preset": "dataset_organization"

},

{

"field_name": "url",

"label": "Source",

"form_placeholder": "http://example.com/dataset.json",

"display_property": "foaf:homepage",

"display_snippet": "link.html"

},

{

"field_name": "version",

"label": "Version",

"validators": "ignore_missing unicode

package_version_validator",

"form_placeholder": "1.0"

},

{

"field_name": "author",

"label": "Author",

"form_placeholder": "Joe Bloggs",

"display_property": "dc:creator"

},

{

"field_name": "author_email",

"label": "Author Email",

"form_placeholder": "joe@example.com",

"display_property": "dc:creator",

"display_snippet": "email.html",

"display_email_name_field": "author"

},

{

"field_name": "maintainer",

"label": "Maintainer",

"form_placeholder": "Joe Bloggs",

85

"display_property": "dc:contributor"

},

{

"field_name": "maintainer_email",

"label": "Maintainer Email",

"form_placeholder": "joe@example.com",

"display_property": "dc:contributor",

"display_snippet": "email.html",

"display_email_name_field": "maintainer"

}

],

"resource_fields": [

{

"field_name": "url",

"label": "URL",

"preset": "resource_url_upload"

},

{

"field_name": "name",

"label": "Name",

"form_placeholder": "eg. January 2011 Gold Prices"

},

{

"field_name": "description",

"label": "Description",

"form_snippet": "markdown.html",

"form_placeholder": "Some useful notes about the

data"

},

{

"field_name": "format",

"label": "Format",

"preset": "resource_format_autocomplete"

}

]

}

(d) DCAT-AP 類別設計

I. DCAT-AP 剖析器(Parser)類別

class RDFProcessor(object):

def __init__(self, profiles=None, compatibility_mode=False):

def _load_profiles(self, profile_names):

class RDFParser(RDFProcessor):

86

def _datasets(self):

def parse(self, data, _format=None):

def supported_formats(self):

II. DCAT-AP 序列化器(Serializer)類別

class RDFProcessor(object):

def __init__(self, profiles=None, compatibility_mode=False):

def _load_profiles(self, profile_names):

class RDFSerializer(RDFProcessor):

def _add_pagination_triples(self, paging_info):

def graph_from_dataset(self, dataset_dict):

def graph_from_catalog(self, catalog_dict=None):

def serialize_dataset(self, dataset_dict, _format='xml'):

III. RDF DCAT 輪廓(Pofile)類別

class RDFProfile(object) :

def __init__(self, graph, compatibility_mode=False):

def _datasets(self):

def _distributions(self, dataset):

def _object(self, subject, predicate):

def _object_value(self, subject, predicate):

def _object_value_int(self, subject, predicate):

def _object_value_list(self, subject, predicate):

def _time_interval(self, subject, predicate):

def _publisher(self, subject, predicate):

def _contact_details(self, subject, predicate):

def _spatial(self, subject, predicate):

def _license(self, dataset_ref):

def _distribution_format(self, distribution,

normalize_ckan_format=True):

def parse_dataset(self, dataset_dict, dataset_ref):

def _extract_catalog_dict(self, catalog_ref):

def graph_from_dataset(self, dataset_dict, dataset_ref):

class TaiwanDCATAPProfile(RDFProfile):

def parse_dataset(self, dataset_dict, dataset_ref):

def graph_from_dataset(self, dataset_dict, dataset_ref):

IV. RDF 資料收集器(Data Harvester)類別

87

class DCATRDFHarvester(DCATHarvester):

def info(self):

def _get_guid(self, dataset_dict, source_url=None):

def _mark_datasets_for_deletion(self, guids_in_source, harvest_job):

def validate_config(self, source_config):

def gather_stage(self, harvest_job):

def fetch_stage(self, harvest_object):

def import_stage(self, harvest_object):

(e) 命令列程式界面設計

I. DCAT-AP 轉 CKAN - consume

此命令列程式會呼叫 DCAT-AP 剖析器(Parser)

python ckanext-dcat/ckanext/dcat/processors.py consume

catalog_pod_2.jsonld -P -f json-ld

II. CKAN 轉 DCAT-AP – produce

此命令列程式會呼叫 DCAT-AP 序列化器(Serializer)

python ckanext/dcat/processors.py produce examples/ckan_dataset.json

e 成果展示

共擴充了 DCAT-AP 所定義的 5 個必備(Mandatory)類別、

4 個推薦(Recommended)類別、15 個選用(Optional)類別，其中

資料集擴充了 12 個欄位，資源擴充了 2 個欄位，詳細說明如

下：

(a) DCAT-AP 擴充資料集

具有編輯權限的使用者登入後，可以新增、修改詮釋資料

欄位擴充至相容 DCAT-AP 1.1 的 CKAN 資料集。

擴充前的 CKAN 資料集如下圖，共有 Title、Description、

Tags、License、Organization、Visibility、Source、Version、Author、

Author Email、Maintainer、Maintainer Email 共 12 個欄位。

88

擴充後的 CKAN 資料集如下圖，共新增 Identifier、

Theme/Subject、Language、Documentation、Frequency、Other

Identifier、Location、Start / End date、Access、Standard、

Provenance 12 個欄位。

89

90

(b) DCAT-AP 擴充資源

具有編輯權限的使用者登入後，可以新增、修改詮釋資料

欄位擴充至相容 DCAT-AP 1.1 的 CKAN 資源。

擴充前的 CKAN 資源如下圖，共有 URL、Name、

Description、Format 4 個欄位。

擴充後的 CKAN 資源如下圖，共新增 Status、Checksum 2

個欄位。

(c) RDF DCAT-AP 服務端點

91

使用者可以使用以下的方法呼叫 RDF DCAT-AP 服務端

點。

https://{ckan-instance-host}/dataset/{dataset-id}.{format}

例如輸入 http://thedatahub.org.tw/dataset/car 可以瀏覽擴充

至相容 DCAT-AP 1.1 的 CKAN 資料集的詮釋欄位

輸入 http://thedatahub.org.tw/dataset/car.ttl 可以轉換成RDF

DCAT-AP 格式

92

二、計畫已獲得之主要成果與重大突破(含量化成果 output)

(一)績效指標

屬

性

績效指標

類別

績效指標

項目

107 年度

效益說明 重大突破 原訂

目標值

實際

達成值

1.擴展促成國際合作資料應

用案例

• 建立 1 個跨國資料混

搭應用合作示範案

• 與國內外各至少 1 個

組織、機構或企業進行

資料互連驗證

1 1

•持續共同推

動亞洲開放資

料共通 API 及

標準，協助資

料產業接軌國

際，跨入國際

資料應用市場

•擴散區域合

作夥伴關係

策略，連結全

球數位經濟

生態體系。

2.深化跨國資料處理技術與

工具

• 推動至少 1 個領域別

跨國資料共通 API 格

式標準

• 擴增 1 個領域別跨國

開放資料互通技術及

規範

• 擴建 1 個領域別共通

語彙基盤

• 擴增 DCAT-AP Data

Model

1 1

•深化多語系

資料處理技術

缺口，引領跨

國資料應用模

組開發。

•擴增DCAT-AP

Data Model 資

料控制管理技

術，以及開發

跨國資料共通

之詮釋資料集

連結標準及模

組。

•擴增跨國水

利災防資料領

域資料應用模

組之互通技術

規範，有效地

植入國內數位

產業國際資料

服務產業能

量。

˙透過資料統

整(Havesting)

介接技術，達

到國際的資料

匯流與交換平

臺功能。

93

三、主要成就及成果之價值與貢獻度(outcome)

(一)經濟效益(經濟產業促進)

深化與亞洲開放資料合作夥伴「資料分析平台與應用合作」協

議，輔導國內資料產業(企業、社群或新創團隊)，透過實證台泰跨

國協作水利防災資料互通技術及共通 API，以及建立台泰智慧水利

防災資料混搭應用合作，有效於技術面與資料面與各國進行實質合

作。

同時協作技術導入國內企業應用產品，並與泰國組織或機構完

成資料互連驗證，推動資料互通分享並帶動應用服務發展，提升國

內產業國際資料服務能量，拓展國際數位經濟商機。

四、跨部會協調或與相關計畫之配合

本計畫著眼於配合貴機關所執行經濟部工業局 107 年度「資料

服務產業應用推動計畫」的主軸，以跨國交換技術研發與實證為核

心，透過與國內潛在特定領域資料團體或公司協作促成推動跨國資

料互通案例，支援「發展多元創新資料服務」的成果與成效。其核

心為進行技術/工具提供及協作技術導入國內企業應用產品，解決

跨國資料互通應用服務之技術需求與問題。

另外，橫向與水利署新南向國際交流計畫協同合作規劃，歸納

幾項推動水利防災產業跨國服務策略共識合作方向如下：

1. 與當地政府簽署水利防災合作意向書，協助該國水利防災開放

資料發布制度建置，取得水災事件、水文觀測、水文環境等穩

定開放資料來源。

2. 與當地學術單位簽署應用技術合作意向書，協助蒐集當地化需

求、應用情境、及跨國互通技術驗證。

3. 國內廠商透過當地學術單位育成當地廠商代理商或提供技術

轉關係，提供當地政府水利防災服務，而國內廠商間接遠端提

供資料應用服務。

94

五、檢討與展望

(一) 持續強化計畫發展跨國資料交換平臺之跨語系資料處理技術

台日協作農業活動及台泰水利災防資料應用案例，落實跨

國資料應用實務驗證結果(如跨語系資料互連檢索應用技術、跨

國資料集採集、跨國多語系翻譯管理等功能的資料互連驗證)。

期間完成台日農業活動資料鏈結互通技術驗證；再複製跨國資

料技術，結合產業擴增水利防災產業資料共通知識本體，並與

泰國組織或機構完成資料互連驗證作為未來推廣國內企業使

用農業/防災等跨國資料共通 API 應用成果，擴散成農業/防災

開放資料經濟生態系，有效地降低處理資料時間及成本、跨領

域資料整合應用門檻。同時，結合產業協作擴增關鍵新主題(如

交通領域別)跨國資料鏈結技術互通與實證，逐漸彌平不同國家

間資料集描述語義落差，提升跨國資料處理技術與資料互連能

力，接軌國際資料市場活動。

(二) 深化計畫所研擬跨國開放資料統整平臺及互連規範書

隨著極端氣候變遷帶來衝擊，東南亞水利防災國際合作需

求迫切，相對跨國間水利防災資料鏈結互通相關技術及規範建

置，有助於國際水利防災合作即時訊息整合，但計畫面對跨國

水利防災開放資料應用產業技術成熟度依不同應用領域需求

有所差異(資料互通標準化、機器自動判讀等)，在補足跨國水

利防災資料產業生態鏈中各階段的能量考量下：(1)依國內各水

利防災資料應用領域產業需求，可逐漸透過開放資料平台進行

共通性資料服務互通性與標準化介面(如(Open API、DCAT-AP

及 ODIP 等)驗證，做為制定互通性參考規範依據；(2)倘若面

對水利防災領域跨國開放資料互通技術，搭配推動跨國創新水

利防災資料應用案例，有計畫性地逐步著手蒐集水利防災領域

的國際資料管理介面標準(如防災管理訊息國際標準共通示警

協定(CAP)、水文觀測資料標準 SensorThings API、水文環境資

料標準 WaterML、以及可延伸觀測知識本體 OBOE 等)，有助

未來於推動產業發展跨國水利防災資料處理技術管理與應

用，勾勒出特定水利防災領域的資料應用技術藍圖需求。

95

(三) 計畫延續雁行理論為推動構想，強化孵育與協同資料應用廠商

於不同領域的開放資料創新應用技術發展，擴展各領域的跨國

開放資料場域實證之可能性，累積潛在資料應用團隊與各國洽

談群創新聚案例經驗，構築各領域跨國資料應用生態系形成，

建立跨國合作接地氣人脈，有助於國際開放資料接軌拓展建構

實質合作關係，延伸發揮計畫成果效益，帶動相關可能國際合

作資料應用案例，媒介國內資料產業鏈接處理國際資料服務機

會，擴展我國在資料市場版圖及商機。

本案跨國示範應用及產業推動後續推廣精進之處建議說

明：

1. 透過參加國際展示活動，提升跨國合作機會

如今年透過 Secutech 2018 台北國際安全科技應用博覽會

之國際展示活動，邀請泰國、越南、菲律賓及尼泊爾洽談

水利防災國際合作，取得第一手可能合作議題與需求，以

及建立跨國初步人脈。

2. 攜手產業協會規劃參訪團，鏈結產業接地氣

與社團法人臺灣防災產業協會合作，遴選產業代表性廠商

組團共赴泰國訪問，建立當地人脈及鏈結協作議題聯繫管

道、掌握當地管理制度及技術需求，落實產品化及達到服

務在地化可行性，拓展未來商機。

(四) 湄公河資料平台計畫

湄公河開放發展資料中心（Open Development Mekong

Datahub）是東西方管理研究所（East-West Management Institute,

Inc. ，EWMI）所進行的開放發展倡議（Open Development

Initiative ，ODI)專案所開發出的資料中心。

湄公河資料平台計畫整合了緬甸開放發展（Open

Development Myanmar）、寮國開放發展（Open Development

Liao）、泰國開放發展（Open Development Thailand）、越南開放

發展（Open Development Vietnam）五個網站而成一整合的湄公

河開放發展資料中心。

96

湄公河開放發展資料中心專注收集關於開發議題相關的

開放資料，主要分三大主題(網址：

https://opendevelopmentmekong.net/topics)

• 環境和土地

農業和漁業

災難和緊急應變

環境和自然資源

採礦業

土地

• 經濟和工業

經濟和商業

能源

工業

基礎設施

勞工

科學和技術

• 人民和政府

援助與發展

政府

法律和司法

人口和普查

社會發展

城市管理與發展

其中農業、災難和緊急應變、城市管理與發展與本計畫推

動策略是一致。共收集四種類型的資料，分別是

資料集，計 418筆

圖書出版品，計 4753筆

法律文件，計 1714筆

合約文件，計 71筆

在語言方面，湄公河開放發展資料中心希望可以收錄英

文、高棉語（柬埔寨官方語言）、越語、緬甸語、泰語、寮語

六種語言，但目前為止仍以英文資料佔絕大多數，無法支援跨

國資料共通應用。

97

湄公河資料平台計畫整合了緬甸開放發展（Open

Development Myanmar）、寮國開放發展（Open Development

Liao）、泰國開放發展（Open Development Thailand）、越南開放

發展（Open Development Vietnam）五個網站而成一整合的湄公

河開放發展資料中心。參考湄公河資料平台計畫，規劃如何擴

展此成果到其他國家如下：

1. 串聯區域對話與合作平台

透過主計畫推動 Asia open Data partnership (AODP)、國際

開放資料會議(International Open Data Conference，IODC)、

參加國際展示活動、及規劃產業協會參訪團，建立區域當

地人脈，串聯區域對話與合作平台。

2. 建構區域主題共通語彙

透過主計畫推動區域對話與合作平台，推廣此成果到區域

共識資料應用之主題案例，在 108 年尋求與湄公河資料平

台計畫合作跨國資料共通應用主題，與跨國開放資料平臺

及互通規範研究，規劃蒐集區域開放資料集，以及建構區

域主題共通語彙之可行性分析。

3. 發展合作夥伴生態系統

依據 108 年與湄公河資料平台計畫合作研究報告成果，於

109 推動跨國資料共通應用計畫，加速擴散多國間專業領

域別跨國資料共通 API 之跨國組織、機構、或團體使用數

目及使用次數，逐漸發展合作夥伴生態系統。

(五) 對政府開放之資料提出具體建議

建議主計畫可規劃定期諮詢蒐集 Open Data 聯盟與各公協會，

對各產業領域別新增實際開放資料需求類別及分析對應解決

產業領域別問題群交集，再盤點政府開放資料來源，或 Open

Data 聯盟與各公協會協作規劃創造新產業開放資料需求來源

專案，以利注入階段產業遲須發展創新所需開放資料源。