個別的是列在那一頁的下面。
是。
主委的意思是比較大地區的流行疾病提醒嗎? 今年衛福部有編列第二預備金規劃開發提醒機制，他們可能會結合手機的簡訊，這部分已經有提出計畫了。
既然在108年的規劃案要做之前，我想這兩個禮拜的測試就非常重要，所以財政中心必須要深入跟團隊規劃測試，用什麼測試方法，我們才可以找到該解決的問題，接下來才能討論解決方案。
包含108年的標案，也應該考量到AP調整的需求，一併要考量進來。
所以其實剛剛政委建議的是，我們接下來的這一個報稅程式應該符合雲端資源調整的架構去做調整，當然程式必須作必要的調整，才能真正彈性做資源運用，在硬體的部分，我們不要做固定的投資、購買，而是用租賃的方式，去應付短期大量的需求，才能真正解決我們現在面臨到你們週期性業務的財政中心的問題，不管是合約或者調整，我相信財政中心可以作這樣的規劃。
如果今天投入大量的資源去投入硬體設備，可是一年只用一次的時候，兩年後、三年後，硬體設備會追不上軟體開發的速度，我們又得再花錢買設備。
設備放哪裡都不是問題，政委給的建議是給財政中心參考，報稅不是一年內十二個月都在報，不管是營業稅、綜所稅都是區間，如何因應區間大量需求來考慮硬體設備的提供，現在作法就算是整體委外，概念仍比較像是財政資訊中心花錢去買設備的概念，只是這部分是透過關貿買的設備，且量不太夠。
不好意思，我想請教一下，可以看到簡報第7頁，我們的解決方法（三），有提到RFP包含使用者介面UI、UX的規格，要納入108年的規格書的規劃。剛剛主任有提到108年的標案，現在可能已經在準備了，現在有辦法包含我們的需求嗎？這個部分我們打算怎麼做？RFP規格應該不是太大的問題，而是我們應該要納入什麼？
但是目前沒有看到你們提出來真正技術的問題在哪裡，以及跟你們建議的解法是什麼，可是我目前看到的是，你們提出來的都是合約的問題，我覺得就算合約處理好了、經費也編了例如需要一千萬就編了一千萬，但是這樣的一千萬是不是真正解決問題或者我們只需要五百萬或者是二千萬才能解? 我不知道是不是可以給一個禮拜或者是兩個禮拜時間，真正測試找出現在的問題是什麼，然後提出你們的建議解法。
長期的部分，包含後台重新開發等等，我們可以放到新合約去處理，到108年的時候正式上線，讓它更穩定、讓使用者滿意，但有些要解決的點，我希望明年可以先解決。
先不管合約，其實對於技術團隊先不看合約的問題，因為合約的問題，中心會處理。我們現在先看技術面的部分，我們希望是不是可以再給中心一個禮拜的時間，請你們去測試，我希望可以提出現在版本，我們實際上去測它承載的量可以負荷到什麼程度，假設接下來有兩百萬人同時上線的話，可負載否? 你們認為問題出在哪裡、提出建議解法，我相信中心這邊會評估合約怎麼樣去做適當的調適去處理這一個問題，我們會希望可以在明年度報稅的時候，這一個部分就可以有所改善。
剛剛討論起來的共識，初步目前看起來，大部分可以在106年申報，也就是明年申報可以有所改善，剛政委提到民眾關切的點卻是放在108年的合約處理。
我們今天做的比較是屬於中文翻譯，接下來呢？
對，其實副座要問的是今天開完會之後，我們會如何處理這一個部分的規範。
能解決的是什麼？能解決的是，當機關把資料準備好，對外提供時，我們提升對外提供的便利性，讓接取者提供端與接取端應用更便利，但並沒有辦法解決前面那一整套，我們必須透過不同的機制來處理跟精進，以上。
我們今天還沒有聽到OAS之前，我一直用的稱呼是OpenAPI時，我們對外談的時候，當時我的概念會認為這樣的API，跟我們談的OpenAPI概念一樣，就是這樣的API符合幾個要件，比如是機器可讀、格式開放、目錄可查詢、機器可寫入等等，就是一個開放的API，當時我也不認為是Open Data的API，也就是API的進階化，就是API是開放的，等於Data變成Open Data一樣，會有它的門檻，更進階之後，讓這一支API的讀取或寫入等等更便利。
因此我們會希望機關集中資源，把資料庫、資料品質及領域標準精進改善之後，對外提供API的部分能夠更精進，也就是對外提供資料的時候，不管是對到民眾或是機關間的資料交換，因為過去機關資料交換是我跟你談，蜘蛛網式的連結，自己可以知道現階段有多少可以接，因此可以盤點他的需求，可以提供可以用的API，而這個API我們現在來談的是，這個API本身能不能更精進。
訂定之後，您剛剛談到基礎建設，確實我們現在也有希望以部會為中心，讓基礎建設集中規劃。當然集中規劃的時候，系統必須再造，系統必須再造，也不是一次106年就出去，那個不太可能，我覺得這個是分階段處理。
至於有哪一些領域訂定這一件事，接下來會去處理，也會召開這樣的會議，就政府機關的部分，可能不會是通盤，沒有辦法一次就通盤，可是我們會先抓大樣，來訂定資料領域的標準。
我們現階段要推動機關需要做的事，其實是包含了頻率資料標準的訂定，其實交通部這邊已經在做了，雖然我們也知道很多交通的辛酸史，還有接下來要持續精進，這是第一步，需要這樣的概念讓其他領域來參考。
我今天說這一個規範的定義是什麼，不管Open Data或者是Open API來講，Open並不是萬靈丹，但是是必然的趨勢，並不是Open API或者是Open Data之後，服務就好會變好，或機關的資料就會變好，不會，這是會是一個循環式的，我們在談Open Data，為什麼需要民間的回饋來讓機關改善資料。
……OAS規範的時候，就像我們在談Open Data這麼多議題當中其中一環而已。
但是解決的是，當機關審視過後是Open Data的時候，釋出來必須要有一個授權條款，我們處理的是那個授權條款的那個，因此我們今天要討論……我還是叫它OpenAPI規範……
我打個比喻來看，我們過去在推Open Data的時候，我們談授權規範這一件事，其實我們談了很久，但授權規範訂出來的版本之後，我能夠去解決Open Data品質的問題嗎？或者機關有哪一些資料可以被Open？不行。
剛剛提到共通性會有一個疑問，不管現在是要稱Open API或者是OAS 3等等，能否解決我們資料品質的問題，也就是取得資料應用的這一件事，其實它不難。
就剛剛幾位與會者提的問題，技術性的我想留給AU來回答。
我的意思是區間車跟電聯車不屬於對號車（笑）。
最慢的車比區間車還慢的車……是車型？
不是區間車，也不是……
我們計時（笑）。
聽完大家的問題，再來解釋。
因為您已經講了，有沒有可能聽這三位講。
