在這個情況下，這個資料的可用性，除非有自動化的方式加以驗證，否則壞掉也沒有人知道（笑），基本上漸漸就會壞掉。這個就是資訊科學上所說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，大家都可以有不同的具體目標，以上是充分揭露我的具體目標。
全部回答完了，還有六十秒。我們休息十分鐘，再來討論「討論共通性應用程式介面開放規範-名詞定義」。
大家會先收到逐字稿的連結，裡面有統問、統答的部分，包括了推廣、教育及工具開發，還有在公部門裡面的定位及外界的定位，外界都有相當詳細的討論。
