今天事實上是要來召開OpenAPI規範的專家座談會，OpenAPI的始作俑者應該就是政委，我們擔心OpenAPI這個規範將來是要到機關讓各機關實際運作、試run，看能不能有一定的成效出來，所以我們今天特別情商政委來召開這樣的會議，看這樣的規範是否妥適，或者是否能易於理解，因為我覺得被理解是很重要的一件事。

如果各位與會者給我們相關的建議之後，我想我們都會列入規範的修正建議，也許擇日對外發布，感謝政委的蒞臨指導。

據說現在有十分鐘的主席致詞，我通常講不了那麼久。

今天會有逐字紀錄，這算是機關內部會議，是十個工作天，並不是十個日曆天釋出逐字稿。

十個工作天通常就是兩個禮拜，今天是禮拜幾就是兩個禮拜後的禮拜幾，因為有速錄的關係，所以請各位朋友第一次發言的時候，說一下自己想要怎麼被稱呼，或者是你想講的話，想要去識別化，也可以取一個代號。

今天的主題叫做OpenAPI，其實是我在進來第一天的時候就提出來的想法，這個想法在當時提出來的時候是很傻、很天真的狀態，因為我進來之前是國發會開放資料諮詢委員，我接觸到全部都是開放資料，上一任內閣時也是在他們以開放資料作為機關內部交換的想法脈絡，不過我實際進來之後才發現這個脈絡有各種各樣法規及技術層面的問題，因此後來就做了許多的調整。

裡面我想特別感謝Open Knowledge的始作俑者Rufus Pollock，他來台灣的時候，我們非常深刻討論了兩次，每一次他都是傾囊相授，把這一個概念變得比較清楚。就像剛剛引言人所說的，「名不正，則言不順；言不順，則事不成」，所以跟那兩次跟Rufus Pollock的討論裡面，就把概念差不多定義好了，今天很願意分享，也很願意繼續調整。

這個概念目前已經用在農委會的菜價、防救災系統資訊整合，及國發會Join接GPMnet等等的概念上，已經可以開始實作或者試作的想法，但這個東西我們目前還沒有整理成best practice。先要確定是個better practice，不然馬上叫做best practice是會有問題的。

接下來請這邊簡報，謝謝。

大家好，我是國發會資管處的鄭立源，也就是目前OpenAPI的承辦科，接下來由我為各位簡報OpenAPI的目前狀況。

我們一開始接到這個任務的時候，想要瞭解什麼是一個Open API，原本很傻、很天真以為純粹是RESTful API加上Swagger的規範。什麼是RESTful API？我想這邊很多專家，所以我簡單帶過，RESTful API是一個彈性設計的樣式，而且並不是標準。

Swagger是一個OAI組織訂出來的規格，最主要是讓API產生一份說明文件，然後這一份說明文件，透過產生工具，產生更容易使用的介面。

昨天請教唐政委，經唐政委開示之後，我們把這個認知稍微修正一下，也就是會變成Web API加Data Schema的概念，原先的Swagger裡面，其實是有針對各個資料欄位作一些更嚴謹的要求，是對一個資料欄位描述，這應該算是在Schema的概念，那時以為這樣就是Open API了嗎？Web API其實跟Web Service不太一樣，也就是Web API純粹是在資料存取上的方式，包含的方式可能包含舊有的規範，以及大部分採用新Open API的型態。

我們如果導入Data Schema的話，使用API的人會更清楚API裡面的欄位、型態及定義是什麼。

難道這樣就是Open API嗎？已經劃掉了，經唐政委大大的解釋，Open API其實應該是從Web API加Schema，變成Common API之後，再搭配Open Data而形成的Open API，如果說明不清楚，要再麻煩政委大大補充一下。

工作期程預計，在3月有請團隊完成初稿，希望在5月份的時候，能夠公告最終的版本，今天是3月最後的階段。

今天討論的議題是，有關於OpenAPI的spec，也就是中文版本的適用性，還有字典檔的中英文對照，還有提到OData及GraphQL的部分有沒有需要納入這一個規範當中，大概會針對這三方面進行調整。簡單介紹到這邊。

「名不正，則言不順」，同一個spec在這一份簡報裡面叫做Swagger 3，有把它叫做OpenAPI 3.0，或者是叫做其他的名字。

總之，這個由OAI組織提出，3.0版本的標準，為了大家腦袋不要燒起來起見，以下這份技術文件，按照OAI他們自己的叫法，叫做「OAS」或「OAS 3.0」。

如果要更窄一點的話，是應該叫做「OAS 3.0 RC0」，因為還沒有正式釋出，或者是OAS或者是OAS 3就好了，這個就不會混淆了。

因為到第三版就已經把Swagger這個名稱丟掉了，如果還再講Swagger的話，好像在講第二版。

所以我們今天是OAS 3的中文版本的討論。

中文版本的翻譯，其實我在會前昨天晚上有收到一個Github，已經在「od2016」的帳號裡面，已經存在了一個叫做「OpenAPI Specification」的翻譯。

我大致看了一下，其實滿清楚的。我覺得這裡的重點翻成中文之後的一些用詞，本身是不是容易清楚，這部分我們有排一個專門的時段，也就是11點10分來討論。

在此之前我想先詢問大家，剛才這一套有一點像繞口令的東西，也就是有Web API，但是不一定是RESTful，當然有一些新的Web API，像GraphQL甚至也不把自己叫RESTful，它認為自己比RESTful還RESTful，所以超越了REST。

也有一些新規範，像OData跟RESTful是相容的，可以橋接，是有更完整的Data Schema。

如果完全以OAS 3來講的話，OAS 3是實作最新版的JSON Schema，已經把Swagger 2.0沒有實作的那些欄位都實作進去。

但是這樣的概念，我們並沒有很好的名詞來說，我們跟Rufus討論之後，我們暫時叫做「Common API Standard」，或者簡稱為「Common API」，中文現在是叫做「共通性應用程式介面」。

「Common API」的這一件事主要是我們今天討論的事情，也就是機關內部交換所使用的，但是機關內部交換，其實人民是看不到的，人民看得到的部分，我們經過Open Definition，裡面包含：

1. 它的授權，也就是國發會第一版開放資料授權，目前看起來是無異議通過，即將變成Open Definition的正式授權之一。

2. 它的格式，必須是自由軟體可以讀取的。

3. 它的近用，不能規定要收非常多錢，然後才能夠下載。

以上這三個是Open Definition。

符合Open Definition的資料，經由Common API提供給大家的時候，才是外界看得到的東西。

我們目前的用法，是把外界看得到的東西，叫做Open API。

如果看PDIS網頁，我們是這樣定義，但是這個定義並沒有哪一個字不能改。

除了授權的部分可能白紙黑字要改非常困難之外，其他的部分，不管是翻成中文的時候，說明會有困難或是概念本身有窒礙難行之處，或者任何需要我們增強或者調整的地方，我想我們既然要整篇翻成中文，是不是先討論這個部分？

以下就沒有既定發言順序，任何人想到就可以發言，謝謝。

最早以前我們針對OpenAPI的範圍定義，之前的概念是一支API，當這支API有一些特殊性描述性的規格，但這個API不見得會一定focus在所謂的Open Data。

或者是Open Definition。

對，Open Definition的Data，也許還不到符合Open Definition，因為Open Definition會談到授權的問題，或者是不限制存取的問題。

但我現在想到的部分是，當初在談所謂OpenAPI，是API的開放格式，但可能是在機關內部間兩個資料的交換，但兩個之間的交換，可能沒有辦法完全滿足授權的部分。

對，其實我最早的那一份推廣文件，本來在PDIS上網站，其實有作區分，就是我們提技術規則的時候，Open跟API中間沒有空白，當外面拿到的時候會加空白，但後來發現這個區分，連我們自己都看不懂（笑）。

當沒有空白的時候，指的是OAS，就是大家手上的這一份東西，因為制訂這個標準的人，名字就叫做OpenAPI連寫、沒有空白。

如果結合開放資料作Open API運用，讓民眾有感的時候，那個東西中間就會加空白。

但是，Rufus來的時候是跟我說，沒有人看得懂有空白跟沒有空白的差異。

所以沒有空白的部分，也就是技術規格，像莊盈志所說機關交換的，也許可以說「用OAS來進行交換」，目前有一些機關也用了一些可能別的。

其實OAS之前最大的競爭者就是API Blueprint，我之前全部都是用API Blueprint，後來可能因為Markdown的寫法不太直觀，所以整個被OAS吃掉了，因此現在API Blueprint加入了OAS的聯盟。

同樣道理，微軟不得不釋出OData往OAS的轉換器，把OAS的第三版，擴充到把他們的欄位加進去等等。

應該是說，Swagger 2滿足了worse is better「劣即是夯」的精神：描述力最弱，但最容易上手，所以大家都用，大家都用之後，旁邊設計更好的，就比較少人用，Swagger 2就把旁邊吃掉了，在吃掉的過程中，本來把旁邊一些東西作為Swagger 2延伸的，現在放到OAS 3裡面。

我們講OAS 3就不會跟Open Definition混淆，我們只要不把OAS的「OA」展開成「Open API」，就比較不會混淆。

也就是當機關內部用OAS 3進行交換的時候，不表示符合Open Definition，我們可能也不把它叫做Open API，我們是說「相容於 OAS 3」之類的。

如果硬要用中文講，因為OAS沒有翻成中文，我的想法是符合「共通性資料存取介面」或「共通性應用程式存取介面」或有「共通性」，也就是有共通性的API。

因此OAS的「OA」一展開，不加空白，所有人都搞混，但它的名字真的叫做Open API Specification，所以也不能叫做Swagger 3，因為已經丟掉這一個名字了，我們這樣講，國際上聽不懂。

因此，我想的折衷方案是OAS。

當它叫OAS的時候，也就是在這一條線以上，也就是在機關內部交換的狀況，但是OAS用來讓民間知道、符合開放定義的話，這個時候就叫做「Open API」，這樣民間就知道既符合Open Definition，又是結構化的。

這樣有聽得懂嗎？

非常難懂。

我用中文全部講一次，完全不加英文詞彙，好不好？我全部用中文講一次，如果我講不對，怡君再修正我（笑）。以上這一張圖默背之後（笑）……

因為您已經講了，有沒有可能聽這三位講。

我會先聽這三位講，三位的想法我們用動態滾動方式加到簡報裡面。

聽完大家的問題，再來解釋。

沒問題，是互動式的，但是讓我用二十秒，用中文講（笑）。

我們計時（笑）。

1. 本來機關有一些只能用特定的專屬軟體才能存取的系統，儘量把它用全球資訊網的方式讓它可以存取。

2. 透過全球資訊網讓機器可以讀取，就叫做「全球資訊網應用程式介面」。

3. 這不一定是有明確的資料結構，也就是資料結構可能沒有定義好。我們給它資料結構明確定義的時候，那就有「共通性」。

4. 這個定義的方法之一，是叫做「OAS 3」的規範，而這個規範不一定是開放資料，也就是授權跟存取可能還有限制。

5. 當授權跟存取都沒有限制的時候，也許可以叫做「開放式應用程式存取介面」。

謝謝，我講完了，請專家發言。

我先提一下，其實最早聽到這一個主題，看到OpenAPI也被混淆，也就是可以讓民間借資料用，但是後來發現跟Open沒有任何關係，我滿贊成不要再用OpenAPI，因此我們的討論也不要用OpenAPI，因此「OAS 3」是還不錯的提議。

因此，這一個議題是機關內部要交換資料的時候，如何讓B機關知道拉A機關的資料出來使用，因此OAS 3是一個拉資料的說明書，也就是只要有這一個說明書寫出來之後，機器也可以讀懂如何跨地方要資料，以前我們是用PDF，也就是用什麼網址跟帶什麼參數，全部都是給人類看，OAS 3是把給人類看的說明書變成給機器看，就是這樣的差別。

先不管Open API這一件事了，其實我有幾個疑惑，如果一個機關要採購新軟體或者是新系統的時候，要把OAS 3納入，到時候機關的承辦人要買這一個軟體的時候，如何決定裡面哪一些資料要被列出來，要有一個OAS 3的API可以讓其他人交換資料？

好比今天要採購我自己部會1999的系統，哪一些東西可以變成OAS跟人家交換？如何判斷？我對這一個有比較大的疑惑。

也就是提供哪一些端點（endpoint） ？

其實剛剛一直講到這跟Open API結合，所以這根本沒有結合，所以我附議剛剛講的，用Open API來形容是不恰當的，但是我還是會回過來質疑本來叫做OpenAPI，或者是叫OAS 3，大家回去找的時候還是會回過來找，還是會找到OpenAPI這個字，如果是同一個字或者是分開的字，Open API這個組織是分開的兩個字，並不是同一個字。

不管怎麼推，大家會回過頭來看文件描述的時候，會問這個跟Open Data的關係是什麼。

尤其政委一開始就說這個是開放資料的下一步。

民眾看得到的那一端就是開放資料，不然怎麼看得到？

不一定啊！如果今天是環保署或者是文化部的API要經過註冊的時候使用的，可以在裡面不一定要放Open API，可以選擇這樣的模式來運作。

PTX其實可以用付費方式來收費的時候，不一定要用Open API，可以發現這裡面接資料端的時候，其實跟Open Data完全脫鉤的關係。

剛剛Ronny說這是應用規範的說明，我很好奇的是，我們會有上千萬個API自動化處理嗎？

對。

真的嗎？

是。但是……

……我的意思是，從應用面回來推目標跟目的，因為我們現在看到有一個東西叫做OpenAPI，這是規範，我們從規範這邊來推的時候，的確是規範，我們就按照制度走就好了，但是到底要走到哪裡去？絕對不能跟OpenAPI綁在一起談，我們有成千上百萬自動化處理，開放者需要處理這麼多的API嗎？如果有需要用的時候，我們會拉過來用。

另外，政府端應用的時候，我覺得現在最大的問題是不是在API這一塊，而是讀出來的資料到底會如何使用？

我們講API好了，講information model的時候，就是把後面的東西很清楚，但如果像data.gov.tw網站上那一堆叫做爛資料東西的時候，Open API要如何扮演角色？及如何協助？從目標端回過來講，我推這個東西的目的，這樣才可以很清楚步驟、方向及要求。

我其實滿想知道的事情是，是不是能夠有清楚的目標？並不是只有交換而已，而是真的往所謂的到底往哪裡走？以及在這裡面所扮演的角色是什麼？

就像我剛剛所講的，Open API的組織就是這兩個字，因此再如何澄清都沒有用，從目標端講清楚就夠了。

綜整一下，謝謝。不好意思，我還是叫做「乙類資料」，因為現在畢竟是法規用詞，是有限制才利用的資料。

1. 當乙類資料利用OAS傳遞的時候，這個到底要叫什麼？

2. 開發者現在是看PDF就好了，真的需要一些結構化文件嗎？

3. 量真的有這麼多，多到需要結構化產製的程度嗎？

4. 我們瞭解資料綱要的製作，有助於資訊模型的明確化。但到底如何增進，以及增進到什麼程度？

5. 我們假設推了這個，資料模型在各機關都比較明確化了。但這還是一個手段，究竟目的為何？

差不多是這樣？

是的。

我的想法是，我們其實是為了交換資料，而資料本身是XML或者是JSON的格式，下一步其實是我們對於資料的描述，而這一個資料描述其實分兩類，一個是告訴我們的作者或者是出版日期，另外一個是指裡面的資料結構的Data Schema欄位的意思。

其實PTX在欄位意思的定義花了很多功夫，因為要貫穿所有公共運輸的DB Schema其實不那麼容易，其實有分好幾個層次來看這個問題。

我們從最抽象的DB Schema的concept設計到logical及最後digital的Schema都定義清楚，定義清楚之後也要跟機關溝通、協調、討論及磨合，把這個Schema定義清楚，才可以作資料交換，而不是自己悶著頭，然後自己做，就說資料ok了，這是不可能的事。

這中間會花非常多的苦功來描述，我認為最重要的還是在於領域上的專業，像公共運輸來講，最後抽象到最後，比如時刻表、收費方式，這一些方式訂好之後，可以貫穿到所有的運具，再跟機關來討論，第一年、第二年花了很多苦功，是機關不用動，我們就去寫程式爬資料，以標準的方式提供出來。

第二年當然希望用標準的格式提供給我們，我們的就廢掉，因此就達到資料格式的世界大同，也就是不用來描述這一件事。

剛剛講DB Schema的描述以外，我的理解是OpenAPI的部分，其實是在描述這一個資料提供的方式。

OAS的部分。

對。

一般我也用功了一下，是用JSON或者YAML的格式來描述，這就很容易可以作機器間的溝通。

我想提醒大家的是，剛剛講的資料，而資料撈取方式有一個標準，我們這邊是用OData，我覺得有三個東西是機關建置要考慮的：

第一個是infrastructure，因為要很彈性query那些語法，你的架構如果沒有跟上，你的網站一放上去就會掛，像PTX現在一天是450萬的request，我們開放到現在已經3億多的request。

其實在資料結構每一層環節都要考慮，包含語法及現在用很多巨量網站加給來支撐這個量，可以一台機器就可以撐住request，這當中要花很多苦功，因此要訂這個還要要求壓測很嚴謹、架構很好，才可以撐得住，不是這麼容易，註明C10K的問題。

現在都C100K了（笑）……

……C10M的問題。（笑）

對，就是要討論到這一些，這是infra跟系統的結構。

第二個是Data的infra的結構，就是要如何去清洗資料，把共通性的語言、共通性的Schema抽離出來，可以溝通跟資料交換，所謂的標準是為了交換用的，而交換是我跟他之間的語言有共同的語言、concept及定義，這樣才可以交換。

第三個是目前最辛苦的，就算交換之後，以PTS來講，我收到鄉民的問題千奇百怪，可能對於資料結構的不清楚，就要去解釋這個就是哪一塊，我覺得光這邊就花非常多的功，並不是寫了網站、放上去，那就沒有問題了，很多APP是會壓身家在你的網站上，就是每天看。

甚至有一些更賊，APP就直接連到那邊去了，所以下一步可能還要導入API manager的軟體或工具，像我們家是用Chrome的方式來做這一件事。

因此這三個基本結構，我覺得在定義之前，可能要提醒資料提供單位，必須要這三個資料結構做清楚，不然我相信一上去，你的資料是鄉民感興趣的，你很快就會掛了，這個是我的想法。

謝謝，非常好，我省去講很多話（笑）。

我是工研院的楊文新，雖然來自於法人，但是我的身分是用產業來看這一件事，前面談了一些，大概少了這一個部分。

呼應剛剛談的事情，討論Common API到Open API，我比較傾向Common API是本來就存在的東西，所謂的Web Data Schema的東西。

Common API在以往不同的產業只要開發軟體，本來就有一堆存在，所以有它的運作機制，因此for Open API是不是變成剛剛所談的OAS 3變成是Open API給Open Data，這一件事我覺得會有很多爭議。

因為Open Data本身的定義就是很擴的定義，可以定義成Open Government Data為或者是Open Data for什麼東西。

如果這個定義範圍這麼大，要變成有一個所謂的Open Data，也就是把Common API加Open Data變成是Open API，我覺得這個挑戰非常大。

因為API是資料交換及資料流通的依據，一定要有人使用，後續要有人去用，這才是存在的東西，否則這個是束之高閣，訂了也是白訂，不會有人用，以後就丟在那邊而已。

所以我傾向個人的立場，要從Common API配合Open Data，是不是在角色上稍微定義一下，也就是從Government Data來用，不要把範圍加大到任何產業的Data，只要符合Open的角度丟出來，而每個都符合的話，這樣以後的爭議是不是會更大？

因為PTX有他的想法，另外也有一套想法，如果沒有一套API可以容納所有的東西，現在OAS 3訂了一個框架的概念，但是一定會說有可能是Reference。

第二，定義這個東西挑戰很大東西時，我們從產業的角度看，產業每一個東西都可以為了它定義所謂的technical spec，所謂要的東西，也就是Reference spec，所有的東西都會有它的運作機制，而運作機制就是來定義所謂Reference test，讓大家參考以後，大家會有很多的想法，會有intumentation。

我剛剛講說為什麼從產業來看，Open Data可以帶出產業界的應用跟價值的話，而不是在所謂社會效益跟政府效益來看，那是Open Data的另外一個角度，如果Open Data轉到產業使用角度去看，從這裡來看的話，產業的運作本來就會為他任何要的spec有其組織運作，也就是可能會有一些workshop的討論空間。

我相信像Swagger或者Open Knowledge組織都是因應這樣的推廣而起來，如果台灣的組織是鄉民，那要如何定義？

所以沒有一個top down東西可以運作，本來就是anarchy society，anarchy society也就是希望有很多東西放出來以後，讓大家去產生一個凝聚共識。

如果產業是用de-facto來談這一件事，事實上剛剛維志在談類似data qwerty的概念，也就是如果以data qwerty的sociability來看，也就是對它的要求是什麼，以及現在對spec的要求是什麼。

從應用端退回來就會有要它的tool，也會Reference spec，這是我初步想到的，先丟出來，不見得很有組織，或者是很深思熟慮，一個草稿的想法先丟出來，謝謝。

我綜整一下，確保我有聽懂。

第一，API一定要有人用，如果我們放在採購的加分項目，如何確保至少有一個用戶？如果不是至少一個用戶的話，那就等於是毫無意義的東西。

第二，這邊的具體建議是，雖然開放資料現在至少台灣國發會用的是Open Definition，也就是授權、接取跟格式都要不受限制，但是這個概念其實在產業界或者在其他非國發會的機關，講到Open Data的時候，不一定完全是這個意思，就連Open Data還沒有完全各界標準化之前，現在又再加上一個概念的話，這個概念可能會有傾斜及倒塌之虞。

因此剛剛有具體建議是先限縮在政府的開放資料，至少國發會是主管機關，大家就會按照國發會的定義來說所謂政府開放資料的明確定義，並不會目前跟民間的開放資料，雖然講開放，可是我們說授權亂寫，但還是說開放資料，而不能禁止，因此是不是從開放政府資料的角度，加上共通性的應用程式存取介面，變成開放政府的應用程式存取介面，就不要管民間了，意思是我們制訂給各機關政府用的，並不是給民間用的一套標準，似乎爭議比較少。

第三，這邊有一個狀況是，不管是用Open Definition或者OAS，其實都是從產業或者是社群或者是公民社會行之有年的東西，慢慢把它標準了，是把運行的機制試圖標準化，讓各界知道我們同意這一些東西，這個是由下而上的東西。

但這樣的意思，並不會有一個強力的標準檢證組織說做錯或者是做對，大部分都是靠自動化驗證工具或者是參考的一些軟性東西來作為標準，這是我剛剛聽到另外要提醒我們的。

第四，我們要從實際應用的角度來回推，從OAS的翻譯之外，還會需要建置哪一些工具鏈及工具鏈相關的協定，只有這一些東西都到位了，我們才能確保這個是對大家都有利的政策。

我聽到的是這樣，有沒有第二輪要補充的？

其實有一些是主動性或者是被動性，假設你定義一個規範，要人家去遵守，人格就是被動性的。主動性是可以加強或補充這個好處在哪裡，比如剛剛所訂的標準Schema，其實在品質的提升很有用的，就可以訂這個質域的名稱及範圍對不對。

最後那個推進來的時候，就可以source進來，然後可以選，沒有問題再transform，再放到readies去，所以對品質的提升我覺得很不錯，可以加強這一個優勢。

另外，剛剛講到Open API的優勢，其實也很有優勢。我們在設計的時候，可以定義API的描述，而API的描述定義清楚，可能用YAML描述，就可以用auto test，就可以testing你的API描述是不是ok的，在這樣抽象性的結構去思考串接你的API。

第二，機器指跟機器交換的時候，這個描述的結構邏輯很清楚。

我補充一下，這整件事我認為是邏輯結構的強迫症，什麼意思呢？資料本身有標準XML、JSON，資料有標準XSD，撈取的語法有標準OData、描述本身也有標準OSD。

所以資料格式，雖然這邊舉了XML跟JSON，但是Rufus特別附身在我身上，希望我強調CSV是非常非常重要，絕對不能忘記CSV（笑）。

但是這三種其實都有描述他們的方法，有了XSD、JSON Schema，連CSV都有Data package，並沒有什麼不能描述的東西。

接下來是接取的部分，可以透過OData來接取，可以透過GraphQL來接取，我們當然也可以透過最基本的HTTP——現在全部都要SSL化了，所以加「S」來接取HTTPS（笑），這個「S」要寫成紅的，因為還沒有發生（笑）。

但是我們還是可以在這上面推關於文字描述，我們用中文寫，也是要把它作成一個標準，但是這樣的好處是，好比機器可以翻成英文、測試套件、SDK的各種語言，或者機器可以翻成ETL流程的參數等等，其實這個用處是無限多的。

我們現在雖然在討論這一個，但如果前面沒有這三個東西規劃的話，其實根本做不到這裡來？

Yes。

OK。不知道有沒有要補充的？

原來要討論的目的是機關間能夠互相交換資料，但是到底機關間能夠交換什麼資料我滿疑惑的，例如某個機關包含個人資料或是企業營業秘密資料，理論上也無法直接透過API跟其他機關交換，因此能被交換的東西，理論上也可以被轉化成Open Data？

我進來之後發現，我之前最傻、最天真就是這一點（笑）。

這個是大問題。

另外一個是API的部分，也就是如何定義端點，到底要經過什麼樣的API出來。

像我們在開發的過程中，也就是先設一個不知道有沒有要用，但是先把API開出來，好比我已經有一個使用情境，我要做一個App、網頁，為了要拉一個資料，因此設計出一個API出來，通常API會存在，也就是有一個使用情境要用了。

現在要把OAS 3納入規範中，如果他們沒有情境，根本完全沒有要用API的情況，那要為了OAS 3生一個不知道有沒有用的API出來？

對，是的。兩個都是極為關鍵的問題。

對，就是後續可不可以follow，以及實質的意義、目的在哪裡？

還有嗎？我們統問統答（笑）。

拉到OAS 3，其實溯及到一件事，在資料的部分，因為OAS在框架交換的部分定義這一個問題，早期前幾年因為在不同的W3C也定義相關的規格，也是拉高到這一層來談。

技術的規格當然可以談，但是在使用上，雖然這一個level的角度上看起來好用，可是為什麼會與實際運用gap這麼深，我想這是這幾年大家都在觀察的東西，並沒有一個規格提出來的時候，都認定一定行、一定不行，大家都是一面走都在調。

因此十年前、二十年前也是一直在改，現在不行、哪裡不行就一直改，改到如果有現況可以用，就是一個版本出去就用了。

我後來看OAS 3這一件事的時候，我想的是一個組織要有這麼大的雄心壯志，把很多不同層次的東西拉在一起，的確是要有長久的運作，因此我想到回到一個本質是，在產業界訂這個東西的時候，原型就會分層次的，好比Internet也會分，從早期的OSI layer七層來分，router在第三層、第四層的這一層，但拉到這麼高的時候，就跑到第七層去了，API某種程度大家定義的東西都是在第六層、第七層談這一個論點。

我們已經談到Open Data要有interface，實際上是因為應用需求，所以需要interface，follow一個規格叫做API，而這個也可以用service，也不要follow 是用OAS 3來做，我覺得那個是權利，因為有他的考量，系統要達到什麼功能。

所以我剛剛為什麼會建議Government Data在Open Data領域來定義自己的API for政府用，也就是定義為政府資料的交換，也就是政府功能的交換或Schema交換，自己定義好，就可以用政府自己。

如果這個可行，那麼就延伸，要用到這樣的資料，他一定要來介接，比如交通部的圖資、交通部資訊的資料，如果是follow OAS 3的東西，有一些什麼東西出來要用到，產業要用到，當然就follow接取來用。

政府不要管Geo訂了什麼東西，因為那不屬於政府管的東西，而是政府要做的，而是變成co-work的角度，今天政府是contributor的角度，也就是政府定義交通資訊的部分，contribute到Geo的東西，要來用就是給你參考的東西。

這是很好用的，而我也需要，我就會follow你，我就會把這一個精神帶到產業界的spec。

往往產業界的規格都是誰有用、誰的使用量大，他的聲音就大，聲音大的時候，這會蓋過，這就是大家參考的規定。

我剛剛講的是Anarchy的做法，由上而下push一定會失敗，而是要變成majority是王。當majority多的時候，大家就會follow，至於majority是不是好的？都不一定，但是至少大家認定……

……其他都不存在了。所以是不是好的？完全不是重點（笑）。

Open API是不是有不同層次，也就是不要一個Common API就是一層，是不是要訂層次？

還有沒有？

要反過來幫OAS講話。

大家有沒有發現，我們現在講的東西已經跳脫OAS要定義的東西，已經往前一直拉了，不管是API的建置也好，或者是前面講到資料的定義也好，可是OAS 3是在處理最後一塊，對我來講就是文件整理而已，叫做一個JSON的格式出來而已。

就是機器可讀的使用手冊。

但是這裡有一個很大的問題是手冊描寫夠好嗎？

就是超爛的（笑）。

對！重點在這裡！我們的手冊管理是真的很爛，是定義很爛，而不是格式很爛啊！

那是因為自然語言不適合用來當格式……對不起，你先講（笑）。

我不是說做得怎麼樣，但是花了很大的功夫，因為我去交通部，所以最值得他們是政府來參考及學習的，他們的描述很多都是很糟糕的，但是原始就很糟糕了，並不是你們變糟糕。因此問題就來了，如果把OAS 3推出來之後會比較好用嗎？

你的手冊是指？

API的操作手冊，現在只講那一塊而已，但是我們已經往前一直走，所以我說要幫唐鳳拉回來。

可是我的重點已經在這邊，現在已經走了Swagger，很清楚是要用自動化都可以做，但是問題是裡面任何一條定義……

……的中文描述還是爛爛的，因為還是用中文字寫。

看台鐵好了，普通車是什麼意思？是區間車還是莒光號還是什麼？普通車是什麼意思？

不是區間車，也不是……

……所以一般使用車來講只知道區間車啊！在賣票的時候用普通車來定義我的票價用普通車。

最慢的車比區間車還慢的車……是車型？

沒有，區間車裡面沒有電聯車，在票價裡面沒有定義這個東西！我看過了，沒有！有自強號、復興號、莒光號及普通車，但是沒有區間車、電聯車。

我的意思是區間車跟電聯車不屬於對號車（笑）。

我完全不知道普通車叫做對號（車），我完全不知道，我的意思是原始的東西寫得很爛，你裝在叫做格式化、結構化的東西，還是長得很爛，你可以回過頭來跟台鐵說：「真的很糟糕，是不是要重寫？」

你可以改單一欄位，也就是送修訂或者指出要改的時候，改的成本大幅降低，比起PDF第152頁第3行第7個字來講（比較低）。

是原本系統資料產出的時候就有問題。

對啊！我同意嘛！

我的意思是，你現在改的還是文字上的tune而已，但是又拉回到票價的表格整個都要調整，那就不是只定義這一個東西而已。

我意思是說把OAS 3往前拉回來，拉回來叫他們說這個東西要重新定義，他們花很多時間來做這一件事，也就是問圖的路徑要不要全部寫出來，他們是在做這一件事，但是這並不是因為他們轉成Swagger才會產生的事情，而是發現使用的時候，發現完全不合格，因此才會去談。

因此我覺得應該要拉開來，我當然很想要所有的東西回到層次裡面去定義，這邊所有的定義，每一個欄位都是用Schema定義出來，我發現日期全部還不是用ISO 8601的格式，因為有的還沒有寫。這時我要怎麼辦？

因此這個東西應該要回過頭來定義到這個層次的時候，我們可以往前推了。在這裡面也會發現有這樣要求嗎？

有啊！

那目前推出來沒有啊！

……不是啊！

……其實沒有針對每一塊更詳細定義，為什麼日期要用ISO 8601，有沒有其他的方式？

（笑）你先講完。

我的意思是說，如果真的要推OAS 3的話，我就回到我的目標，剛剛一直講到品質、實際狀況及使用者需求，我可以用嗎？

是啊！

我現在看不出來。

沒問題。

我一直嘗試理解現在講什麼問題，我剛剛是要問什麼叫文件，以我所知，如果今天開發一套系統，也就是要產出一套系統規格書及操作的手冊，這是必然的，這個是軟體工程要求的。

不然不能結案。

這個文件要怎麼寫，這個是一件事，也就是今天要給人家一份系統spec要哪一些，一定有其定義，定義是為了軟體工程如何表達，還有設計的方法論是什麼及如何表達。

但是這邊在談的OAS 3會有辦法去cover這一塊嗎？沒有辦法吧！cover不了吧！我覺得這兩個東西不對等，我是說在寫文件的過程中，如果對使用資料、處理資料的範疇，是不是採用OAS 3的描述方式比較精確，說不定對寫文件的品質是有幫助，但是不代表整份文件要怎麼寫，要怎麼寫，我覺得並不是今天討論（的範圍內）。

如果要談這個，那麼就變成整個軟體文件、軟體工程for Open Data如何產生，也就是國發會是不是要想這一個問題如何定義？

對，這有一整個領域，也就是服務設計、敏捷開發、疊代式等等，如果討論這個，我們今天晚上十點還會在這裡（笑）。

所以我剛剛要嘗試說，兩個問題是不是要分一下，範疇是否也要定調一下？

維志那段我雖然沒有記到（白板上），但是其實您（楊文新）已經幫他綜整了。

軟體設計裡面的資訊模型跟接取設計，做到這裡而已，這個是今天會能夠解決的是這一個。但是我們如果要想像這個解決了，服務設計或流程設計就會魔法般的的變好，這是不切實際的。我想這是所有人的共識。

維志問的是這兩個中間有沒有關聯，如果把上面的資訊、模型設計做出來，然後讓大家都看到目前的資訊模型是怎麼樣，包含那個領域的人對他的認知是否清楚，轉到別的領域的人是否能夠瞭解，以及這個領域跟別的領域在交錯的時候，會不會產生一個字在兩個領域不同意思，然後因此就爆炸的各種各樣狀況。

我打一個不恰當的比方，好比我開會都有逐字稿，但這不表示政府的決策過程就很透明。

但是，逐字稿可以幫大家看到「有多麼不透明」，所以也可以說有一點幫助。

這個幫助是處於一個讓我們知道實際情況的那個程度，而不是因此就會改善的幫助，那需要別的東西。這是我基本的想法。

我同意張維志剛剛別的詢問。我們繼續統問統答。

我補充一下：

第一，定義Schema交換格式的時候，真的是不夠，我們跟來源單位討論的時候，其實有很努力準備Inbound文件，要把所有的欄位、描述講清楚。

第二，要有那個sample的data，要製作給他看。

第三，要加圖形的描述，讓它畫清楚，讓別人知道物理意義的描述是不是理解、大家的定義是不是一樣的，描述清楚之後再溝通，你們才會站在同一種語言上，並不是給他看Swagger就算了，通常都會說看不懂，我非常同意維志講的，並不是Schema訂好之後就可以溝通了，這個不是可行的事。

雖然我們這邊有準備很多Inbound文件，其實這裡面有很多大量的圖例、範例來說明我們要表達欄位的意思是什麼，我們目前是用word，但我覺得要能夠溝通清楚最重要，要把API描述清楚最重要。以上補充。

我入閣前，都是用API Blueprint。雖然跟Swagger一樣，都可以同時容納綱要描述、範例資料及互動流程，但當你用Markdown的時候，你就有一種在寫文件的感覺，因此你會自然覺得只是寫機器描述不夠，還要多寫一些文字，而且附圖很容易，就把圖都裝進來，因此到最後仍然是機器可讀的一份描述檔，但在寫作的過程中，你會自然把這三個寫上去，因為Markdown主要是人跟人間交換的一分文件。

但是沒有人寫JSON跟XML的時候，會覺得這是寫給人看，因為這樣的關係，雖然OAS裡面可以容納資料、圖例及互動流程的地方，大家不會一下子想到那邊去，結果是常常那個地方是空的，好比像API的要求，好比一個寫入好了，其實可以附範例資料的東西，甚至裡面要用超連結或內嵌圖片的方式放進去在說明欄，也沒有不可以，因為不是Markdown，大部分的人不會往這個方向想。

這是為什麼我之前不太喜歡Swagger，但全世界都在用Swagger，沒辦法。

就剛剛幾位與會者提的問題，技術性的我想留給AU來回答。

剛剛提到共通性會有一個疑問，不管現在是要稱Open API或者是OAS 3等等，能否解決我們資料品質的問題，也就是取得資料應用的這一件事，其實它不難。

我打個比喻來看，我們過去在推Open Data的時候，我們談授權規範這一件事，其實我們談了很久，但授權規範訂出來的版本之後，我能夠去解決Open Data品質的問題嗎？或者機關有哪一些資料可以被Open？不行。

但是解決的是，當機關審視過後是Open Data的時候，釋出來必須要有一個授權條款，我們處理的是那個授權條款的那個，因此我們今天要討論……我還是叫它OpenAPI規範……

……OAS。

……OAS規範的時候，就像我們在談Open Data這麼多議題當中其中一環而已。

我今天說這一個規範的定義是什麼，不管Open Data或者是Open API來講，Open並不是萬靈丹，但是是必然的趨勢，並不是Open API或者是Open Data之後，服務就好會變好，或機關的資料就會變好，不會，這是會是一個循環式的，我們在談Open Data，為什麼需要民間的回饋來讓機關改善資料。

我們現階段要推動機關需要做的事，其實是包含了頻率資料標準的訂定，其實交通部這邊已經在做了，雖然我們也知道很多交通的辛酸史，還有接下來要持續精進，這是第一步，需要這樣的概念讓其他領域來參考。

至於有哪一些領域訂定這一件事，接下來會去處理，也會召開這樣的會議，就政府機關的部分，可能不會是通盤，沒有辦法一次就通盤，可是我們會先抓大樣，來訂定資料領域的標準。

訂定之後，您剛剛談到基礎建設，確實我們現在也有希望以部會為中心，讓基礎建設集中規劃。當然集中規劃的時候，系統必須再造，系統必須再造，也不是一次106年就出去，那個不太可能，我覺得這個是分階段處理。

因此我們會希望機關集中資源，把資料庫、資料品質及領域標準精進改善之後，對外提供API的部分能夠更精進，也就是對外提供資料的時候，不管是對到民眾或是機關間的資料交換，因為過去機關資料交換是我跟你談，蜘蛛網式的連結，自己可以知道現階段有多少可以接，因此可以盤點他的需求，可以提供可以用的API，而這個API我們現在來談的是，這個API本身能不能更精進。

我們今天還沒有聽到OAS之前，我一直用的稱呼是OpenAPI時，我們對外談的時候，當時我的概念會認為這樣的API，跟我們談的OpenAPI概念一樣，就是這樣的API符合幾個要件，比如是機器可讀、格式開放、目錄可查詢、機器可寫入等等，就是一個開放的API，當時我也不認為是Open Data的API，也就是API的進階化，就是API是開放的，等於Data變成Open Data一樣，會有它的門檻，更進階之後，讓這一支API的讀取或寫入等等更便利。

能解決的是什麼？能解決的是，當機關把資料準備好，對外提供時，我們提升對外提供的便利性，讓接取者提供端與接取端應用更便利，但並沒有辦法解決前面那一整套，我們必須透過不同的機制來處理跟精進，以上。

這有沒有回答到關於PTX的三個問題？

剛剛具體的回應是，延展架構現在是機房向上，不只機房，也就是所有的基礎建設，但也不是馬上完成，逐漸向上、仍然向上的節奏（笑），讓三級或者是一些最基本基層的機關不用自己弄CDN，不是那麼容易一件事。

另外，資料清洗或抽取，可以從三級機關或甚至更底下的暗管——我們叫暗管好了——至少在二級機關都可以看得到目前有哪一些暗管，再把明管的索引製作出來。

第三，維護跟輔導服務也不會是我寫出這一個程式就養它一輩子，而是可以有一個專業的維護及輔導的團隊，讓大家知道如何應用所有二級底下的API。這樣有回答到嗎？

其實我們有分好幾個步驟，第一個我們談scale up，就是討論到這個機器本身的CPU，最重要的還是語法，也就是要解決資料最終一致性的問題來處理，這個完之後才是scale out，我們就引進很多反向代震技術（音譯）。

這個是C10M，還沒有辦法處理的境界，才會到CDN，我稱為「多樣性的處理方式」來處理，也就是用API manager各種不同服務的觀點來切分這一件事，老實講目前其實在scale out做好就夠了。

雖然很多朋友愛說「大數據」，但實際上往往都是中數據，至少流量的部分是；一台電腦能處理就是小數據（笑），絕大部分交換資料都是小數據，在這樣的情況之下，其實真的用不到大數據那個層級的架構，很感謝這個澄清，非常重要。

所以這張如果ok的話，我們就接下來。

因為11點要稍微休息一下，因此儘量簡短、統問統答，我講得也不一定都對，所有目前有用不同顏色畫的都是未來措詞上馬上可以改的。

並不是我這邊講的，接下來都不可以改。隨時都可以改。

「如何讓寫文件的工具更友善到，大家能夠學著把範例資料跟圖例也都整合進OAS裡面？」

這是協作環境的工具選對了，或者是目前有一些現成，但是是私有軟體，我們團隊也有在用，而且還用mac的一些專門API開發工具，可以讓你非常容易在測試的過程中，甚至是在對一個既有的，其實根本沒有OAS使用網站過程中，就是把初步的規格寫到六成的工具，它當然是存在的；但因為道德元素，它不是自由軟體，所以我不能講它的名字（笑），在這樣的前提下，這是可以靠工具就可以改善的，我只想講這一個。

軟體設計上如果只是把綱要講清楚，不表示它的領域就講清楚了，更不表示這個領域在跨領域的流程是清楚的，這是大家的共識，我們解決這一件事，絕對不能解決最外面的，就像怡君所說的，只是一個層面引導作用而已。

「機關對個資交換的權限？」

我本來很天真，真的跟Ronny想的一樣（笑），本來跨機關的時候不能交換個資，既然本來不能交換個資，不是打一個勾就變成Open Data嗎？但完全不是這樣子（笑）。

這裡面有非常多的暗管，我分成三個快速講：

第一個是，真的有個資，但是個資在一定情況下，可以往上級機關交換，好比像健保署到衛福部，這個時候只要有證明良好保存這一個資料，即使明明沒有完全去識別化，我們的最高行政法院還是會判合法。因此在這一種情況下，絕對不可能是Open Data，因為是由下而上垂直的處理。

第二個情況是，兩個機關間簽了機關對機關的意向書這一類的東西。這並不是結構化的交換機制，而更像是一個函的形式，我同意你依法律授權使用這一些資料，我的個資清洗情況沒有經過認證，但是應該沒有很誇張的、可直接識別的狀況。

也就是說，能不能透過鏈結再重新識別？這個來源機關其實不知道，但是它相信這個依法有處理權限的接收機關，因為是內部使用，所以內部的公務員不會拿去重新鏈結。這兩個機關一發函，其實資料就開始交換了。但是，這個時候如果放出去變成開放資料，那或許是可以重新鏈結再識別的情況，因此也不能轉成Open Data。

第三個是，有時幾個機關一起做某一個專案，其中一個是資料的蒐集端，但是在一開始的時候，在個資聲明就說這四個機關一起做這個計畫，因此這四個計畫都可以使用你所提供的個資，而且使用者也同意了。這裡面一定會產生資料交換，但是按照個資法，他們就是共通處理者，那也不能轉成Open Data，而且這個情況比想像中還多。

因此，我希望未來在設計的時候，就要把個資跟隱私設計進去，不然走這三種便宜行事的道路容易得多，現在就變成並沒有任何東西是我們現在有一個索引，就可以馬上把結構化的資料變成開放資料。

因此，才會變成上一波推開放資料時，常常是拿半結構或者是未結構化的資料來當作開放資料。原因是那些是按資訊公開法，本來就用唯讀方式在網頁上呈現，只要找出原始資料，有時候找不到就用報表資料開放出來，這邊就變成開放資料。

但是跟機關真正在交換的結構化資料，可能完全沒有關係，或這只是統計報表，因此才會變成民間所謂「開放資料是次等公民」的概念，因為原始資料是完整的，而開放資料只有碰巧在出日報表的時候，順便處理一下。所以如果斷掉或者是壞掉了，其實公務作業不受影響。

在這個情況下，這個資料的可用性，除非有自動化的方式加以驗證，否則壞掉也沒有人知道（笑），基本上漸漸就會壞掉。這個就是資訊科學上所說bit rot，比特也會壞掉的狀況——所以我本來以為明管是常態、暗管是例外，後來發現剛好相反過來。

「機構在採購資訊系統的時候，拿API要來作什麼？」

我想像中的回答是：

第一，如果網站本身跟資料寫入、讀取的後端是分開建置，當這個狀況發生的時候，也就是解耦架構，甚至前、後端可以分別採購。

這是讓它不得不使用API來溝通，因為如果不使用API溝通，連前端都做不出來。

在這樣的情況下，至少有一個使用者，也就是這個前端的使用者。

如果接下來標案都能寫成「前、後端分別建置」，其實這個問題根本不存在，因為這樣API至少有一個使用者。

但我們也知道，標案不太可能馬上全都改成這樣寫。

另外一個方向是，在建置的時候，就想說哪一些資料未來可以作為跨機關的利用使用，然後要找到至少一個上級或是別的需用機關，一起寫下非開標機關的業務裡，需要用到裡面的哪些資料。只要有這樣的機制，至少有一個機關的外部使用者，這時API也會需要的，這個情況比剛剛那個情況常見，但仍然不是常態，這是某些時候會發生的事。

其實這在國發會的案子比較常見，你們處理的是別的機關跟別的機關交換時要做什麼。

我入閣前是國發會的開放資料諮詢委員，我本來以為這個情況很常見，但後來發現我錯了（笑）。

雖然在國發會系統裡面可能滿常見的，但在其他機關雖然有出現，但並不是多數。這兩個是在想像中的通常使用情形。

在這個的情況下，之所以沒有成為必載，也就是採購時一定要滿足的條件，是後來怡君提醒我，其實很多時候機關購買有網頁連線能力的系統，只是因為瀏覽器滿好用的，而不是因為天生就不喜歡其他別的專屬軟體的架構，並不是網頁系統就隱含著想要把這一個資料跟別的機關交換的意思。

我記得本來說要強制，後來變成加減分，後來變成某一個特定廠商有這個能力的加分，如果我沒有記錯的話。

有記錯請現在跟我說，我們在跟工程會……

……那時候列為評選的加分項目。

對，所以機關如果需要、有這一個使用情境的話，就變成加分項目；但是如果機關實際上沒有這個使用情境的話，也不需要列。

後來跟工程會談完之後是這一個版本，這個就是沒有那麼傻跟天真的版本。

這是回答第二個具體，我本來想像中採購的情境。

第三個並不是一個問題：「政府作為一個資料提供者，不只是接取、也有存入的API示範」。

這中間因為國發會會協調一些領域的資料結構標準，因此在這樣的情況下，有一些有用的規格會因此而冒出來，但並不是強制全國使用，這是大家用用看看，也就是貢獻者的態度，我相信這部分是沒有問題的。

接下來，假設現在有這一個需求，也在標案中寫了，因此採購到的機關，對於其資料品質的自動驗證、對於ETL的流程、對於自動生成SDK等等，這可能需要教育的部分。就是存在著這一些工具，而這些工具如果良好運用的話，不只是在驗收，甚至開發的過程中，都可以比較省你的力氣。

再者提出的問題是：「為什麼大家想到這一整串的時候，沒有想到Web Ontology的那一整套架構？」

原因是那是非常由上而下的東西，而要全部都想好才寫得出來，但是實際上在開發系統的時候，哪有這一種事，都是想一半就寫，寫了之後，大家覺得不好用再改，在這個時候用Web Ontology的這種方式來設計時，每一次改的成本真的比較高，這個是實話。

因此這是以我所知，台灣政府機關很少用Web Ontology來作交換的原因，所以這邊列的，不管是JSON、XML、CSV都是非常簡單的語法。

語義層可以訂到這是日期，但是沒有結束的年、月、日的東西，也就是比較鬆的東西，不管是資料封裝或是地理資料或是XSD或是JSON Schema，其實如果想要訂細一點，是可以訂細的空間，也就是還沒有想那麼清楚的時候，你的欄位增刪，或者定義比較舒適也可以，所以這個是漸進的過程，這個是具體的回答。

「如何確保至少有一個用戶？」這個剛剛有回答到了。

限定說「這只是政府邁向資料開放的一環？」

我完全同意，我相信這個是非常好的見解，如果大家沒有反對的話，我們就往這一個方向走。

工具鏈跟協定跟剛剛講的一樣，運作機制的參考，這是有必要的，確實是這樣子。

實際有參與的幾個系統，我想也可以慢慢寫成簡報，然後把「Join」的串接或是菜價的串接或是防救災裡面運用到OAS的哪一些精神，也可以加以進一步說明，這個部分有回答過了。

接下來是最早的問題：「到底如何教育採購的機關去開端點？」

這個是非常好的問題，如果有一個良好服務設計的流程，理論上這應該是在服務設計一開始的那份文件轉變成端點，我們在軟體工程上叫做「使用者故事」。

但是如果不是用敏捷方式來開發的話，確實沒有自然的方式從使用者的需求直接轉換到端點。

這個時候只能退而求其次，如果前後端採購的話，用介面操作當端點，或者如果是機關之間有交換，或者共用資料需求的話，用交換的端點當端點，可能只有這兩個端點的來源，這是具體的回答。

接著是「乙類資料在對外交換的時候，到底要叫做什麼？」

乙類資料對外交換的時候，除了某一個特定機關之外，都已經沒有叫Open Data了，那個特定機關我們再想辦法（笑）。

所以乙類可能不符合開放定義裡面授權的部分，而只符合格式，因為如果是OAS，當然符合格式的部分。

因為乙類資料也有對外，所以也有接取的部分，但如果這個資料要收非常多錢，那是一回事，授權如果不能作商業利用，又是另外一回事。

如果有這兩類限制的話，我也不認為應該叫做「開放政府API」，我相信這個是最要確定、最不能混淆的地方，否則「開放」二字又再次喪失意義。

接下來是「開發者是否真的對於結構化的文件有其需求？」

一個是當你系統只是開發跟自己用的時候，確實除非是開放團隊大到沒有辦法在同一個會議室開會，否則這個文件的意義沒有很大，這個是說真的。

我自己在業界的時候，之所以會那麼強調這一個東西，是因為我們在印度、加拿大、台灣、英國、美國兩岸都有人，這時大家沒有辦法聚在白板上開會，這個文件的自足性就變得非常重要，因為沒有寫清楚的話，不同時區跟不同文化的人，根本不知道你在講什麼。

因此這一個情況下，多機關、多利益關係人的資料運用時，這一份結構化文件的價值才會彰顯出來。

如果所有參與開發專案的人都是領域專家，而且他們都彼此認識、十年交情，在有白板的房間，根本不需要結構化技術說明的文件，這個是確實的。

「資料綱要如何增進資料品質？」

就像剛才所說的，資料綱要只能協助我們看清楚資料品質目前到底多差，並不能讓我們改善資料品質，但如果不知道目前到底哪兩個部分差、哪三個欄位還可以，到底如何改善資料品質，除了打掉重寫之外？所以我覺得這個透明度本身還是有幫助。

目標當然是希望盡可能多機關間的暗管，也就是「如果承辦或者廠商一換掉，就會完全喪失溝通能力」的那些暗管，透過這樣的過程慢慢轉變成是能把標案切小，或是換廠商或是換承辦人時，本來累積的那些領域知識不會完全消失。

這是具體的目標，至少是我具體的目標。同樣一個OAS，大家都可以有不同的具體目標，以上是充分揭露我的具體目標。

全部回答完了，還有六十秒。我們休息十分鐘，再來討論「討論共通性應用程式介面開放規範-名詞定義」。

不好意思，因為我剛剛中途有一點離開，不曉得後續要如何繼續鋪陳這一件事？做法是什麼？

大家會先收到逐字稿的連結，裡面有統問、統答的部分，包括了推廣、教育及工具開發，還有在公部門裡面的定位及外界的定位，外界都有相當詳細的討論。

所以我覺得是不是先摘出來，變成是一個類似問答集的格式，那樣的東西我覺得再去修改，修改到某個程度就可以變成教育訓練或什麼的。

對，其實副座要問的是今天開完會之後，我們會如何處理這一個部分的規範。

我們今天做的比較是屬於中文翻譯，接下來呢？

接下來的部分是這一個版本不是最終版，也許是草案的版本，比如可能還是會對外徵集，對這一個版本有沒有相當的確定；取得大家共識、徵集後，然後再辦理發布的程序。

所以徵集也會到「Join」嗎？

「Join」變成是只能在「眾開講」那邊來談。

其實現在「來監督」也寫了很多。

可是「來監督」比較是政策形成後期。

所以就會變成「來監督」的某一個分項再來「眾開講」談一下，因為目前「來監督」上已經有這一個東西的討論。沒有人知道嗎？

之前是在談那個……

……執行進度那個已經下架了。

一個是工程會Open Data。我們本身的「來監督」還在，那個一直到年底。

其實後續的東西還要工程會，會在未來的招標範本裡面去……

他們只會放reference？

只會擺規範的名稱。

可能也要跟他們討論一下，不可能擺一個他們自己都不是很理解的東西。

是啊！這個我同意。

還是要跟他們去溝通。

所以先把剛剛那個整理成統問統答，附一個連結到逐字稿，十四天之後會公開，十四天之後放到「眾開講」去，然後跟大家說有這樣的一件事，雖然跟「來監督」裡面某個子議題有一點重複，但是這個spec本身是接下來要推行，因此要當作是政策前期的溝通，如果大家沒有問題的話，這樣可以嗎？

OK。

未來可以跟業界，比如協會，可以把這整份給他們。

對，可能就是要有一個類似說帖的東西，今天開場的簡報稍微加幾張還不錯，所以我覺得把剛剛手寫簡報的元素加到開場簡報裡面。

剛剛共識是這一份標題就不要再出現OpenAPI字樣了，內文提到時就寫OAS 3。

中文標題就不用改，中文很好。

叫做「共通性應用程式介面開放規範」。

對，這個應該沒有人有爭議，在這個裡面其實講規範本身是開放的，並沒有說被規範的東西是開放的，這樣就應該說得通。

好，所以應該就這樣。今天謝謝大家！