我進來之後發現，我之前最傻、最天真就是這一點（笑）。
對，是的。兩個都是極為關鍵的問題。
還有嗎？我們統問統答（笑）。
……其他都不存在了。所以是不是好的？完全不是重點（笑）。
還有沒有？
就是機器可讀的使用手冊。
就是超爛的（笑）。
那是因為自然語言不適合用來當格式……對不起，你先講（笑）。
……的中文描述還是爛爛的，因為還是用中文字寫。
你可以改單一欄位，也就是送修訂或者指出要改的時候，改的成本大幅降低，比起PDF第152頁第3行第7個字來講（比較低）。
對啊！我同意嘛！
有啊！
……不是啊！
（笑）你先講完。
是啊！
沒問題。
不然不能結案。
對，這有一整個領域，也就是服務設計、敏捷開發、疊代式等等，如果討論這個，我們今天晚上十點還會在這裡（笑）。
維志那段我雖然沒有記到（白板上），但是其實您（楊文新）已經幫他綜整了。
軟體設計裡面的資訊模型跟接取設計，做到這裡而已，這個是今天會能夠解決的是這一個。但是我們如果要想像這個解決了，服務設計或流程設計就會魔法般的的變好，這是不切實際的。我想這是所有人的共識。
維志問的是這兩個中間有沒有關聯，如果把上面的資訊、模型設計做出來，然後讓大家都看到目前的資訊模型是怎麼樣，包含那個領域的人對他的認知是否清楚，轉到別的領域的人是否能夠瞭解，以及這個領域跟別的領域在交錯的時候，會不會產生一個字在兩個領域不同意思，然後因此就爆炸的各種各樣狀況。
我打一個不恰當的比方，好比我開會都有逐字稿，但這不表示政府的決策過程就很透明。
但是，逐字稿可以幫大家看到「有多麼不透明」，所以也可以說有一點幫助。
這個幫助是處於一個讓我們知道實際情況的那個程度，而不是因此就會改善的幫助，那需要別的東西。這是我基本的想法。
我同意張維志剛剛別的詢問。我們繼續統問統答。
我入閣前，都是用API Blueprint。雖然跟Swagger一樣，都可以同時容納綱要描述、範例資料及互動流程，但當你用Markdown的時候，你就有一種在寫文件的感覺，因此你會自然覺得只是寫機器描述不夠，還要多寫一些文字，而且附圖很容易，就把圖都裝進來，因此到最後仍然是機器可讀的一份描述檔，但在寫作的過程中，你會自然把這三個寫上去，因為Markdown主要是人跟人間交換的一分文件。
但是沒有人寫JSON跟XML的時候，會覺得這是寫給人看，因為這樣的關係，雖然OAS裡面可以容納資料、圖例及互動流程的地方，大家不會一下子想到那邊去，結果是常常那個地方是空的，好比像API的要求，好比一個寫入好了，其實可以附範例資料的東西，甚至裡面要用超連結或內嵌圖片的方式放進去在說明欄，也沒有不可以，因為不是Markdown，大部分的人不會往這個方向想。
這是為什麼我之前不太喜歡Swagger，但全世界都在用Swagger，沒辦法。
……OAS。
這有沒有回答到關於PTX的三個問題？
剛剛具體的回應是，延展架構現在是機房向上，不只機房，也就是所有的基礎建設，但也不是馬上完成，逐漸向上、仍然向上的節奏（笑），讓三級或者是一些最基本基層的機關不用自己弄CDN，不是那麼容易一件事。
另外，資料清洗或抽取，可以從三級機關或甚至更底下的暗管——我們叫暗管好了——至少在二級機關都可以看得到目前有哪一些暗管，再把明管的索引製作出來。
第三，維護跟輔導服務也不會是我寫出這一個程式就養它一輩子，而是可以有一個專業的維護及輔導的團隊，讓大家知道如何應用所有二級底下的API。這樣有回答到嗎？
雖然很多朋友愛說「大數據」，但實際上往往都是中數據，至少流量的部分是；一台電腦能處理就是小數據（笑），絕大部分交換資料都是小數據，在這樣的情況之下，其實真的用不到大數據那個層級的架構，很感謝這個澄清，非常重要。
所以這張如果ok的話，我們就接下來。
因為11點要稍微休息一下，因此儘量簡短、統問統答，我講得也不一定都對，所有目前有用不同顏色畫的都是未來措詞上馬上可以改的。
並不是我這邊講的，接下來都不可以改。隨時都可以改。
「如何讓寫文件的工具更友善到，大家能夠學著把範例資料跟圖例也都整合進OAS裡面？」
這是協作環境的工具選對了，或者是目前有一些現成，但是是私有軟體，我們團隊也有在用，而且還用mac的一些專門API開發工具，可以讓你非常容易在測試的過程中，甚至是在對一個既有的，其實根本沒有OAS使用網站過程中，就是把初步的規格寫到六成的工具，它當然是存在的；但因為道德元素，它不是自由軟體，所以我不能講它的名字（笑），在這樣的前提下，這是可以靠工具就可以改善的，我只想講這一個。
軟體設計上如果只是把綱要講清楚，不表示它的領域就講清楚了，更不表示這個領域在跨領域的流程是清楚的，這是大家的共識，我們解決這一件事，絕對不能解決最外面的，就像怡君所說的，只是一個層面引導作用而已。
「機關對個資交換的權限？」
我本來很天真，真的跟Ronny想的一樣（笑），本來跨機關的時候不能交換個資，既然本來不能交換個資，不是打一個勾就變成Open Data嗎？但完全不是這樣子（笑）。
這裡面有非常多的暗管，我分成三個快速講：
第一個是，真的有個資，但是個資在一定情況下，可以往上級機關交換，好比像健保署到衛福部，這個時候只要有證明良好保存這一個資料，即使明明沒有完全去識別化，我們的最高行政法院還是會判合法。因此在這一種情況下，絕對不可能是Open Data，因為是由下而上垂直的處理。
第二個情況是，兩個機關間簽了機關對機關的意向書這一類的東西。這並不是結構化的交換機制，而更像是一個函的形式，我同意你依法律授權使用這一些資料，我的個資清洗情況沒有經過認證，但是應該沒有很誇張的、可直接識別的狀況。
也就是說，能不能透過鏈結再重新識別？這個來源機關其實不知道，但是它相信這個依法有處理權限的接收機關，因為是內部使用，所以內部的公務員不會拿去重新鏈結。這兩個機關一發函，其實資料就開始交換了。但是，這個時候如果放出去變成開放資料，那或許是可以重新鏈結再識別的情況，因此也不能轉成Open Data。
第三個是，有時幾個機關一起做某一個專案，其中一個是資料的蒐集端，但是在一開始的時候，在個資聲明就說這四個機關一起做這個計畫，因此這四個計畫都可以使用你所提供的個資，而且使用者也同意了。這裡面一定會產生資料交換，但是按照個資法，他們就是共通處理者，那也不能轉成Open Data，而且這個情況比想像中還多。
因此，我希望未來在設計的時候，就要把個資跟隱私設計進去，不然走這三種便宜行事的道路容易得多，現在就變成並沒有任何東西是我們現在有一個索引，就可以馬上把結構化的資料變成開放資料。
因此，才會變成上一波推開放資料時，常常是拿半結構或者是未結構化的資料來當作開放資料。原因是那些是按資訊公開法，本來就用唯讀方式在網頁上呈現，只要找出原始資料，有時候找不到就用報表資料開放出來，這邊就變成開放資料。
但是跟機關真正在交換的結構化資料，可能完全沒有關係，或這只是統計報表，因此才會變成民間所謂「開放資料是次等公民」的概念，因為原始資料是完整的，而開放資料只有碰巧在出日報表的時候，順便處理一下。所以如果斷掉或者是壞掉了，其實公務作業不受影響。
