意思是：只要協會這邊被內政部認定的時候，沒有排除掉你們是有體育宗旨，這邊認定完成了，協會並沒有被排除適用別的原因；相反的，如果當時被認定的是已經不含這個宗旨，這邊就要做什麼？
所以是第26條第1項會按照實際協會目前的宗旨去做個案的認定，第2項的部分，我們說是在辦法層次去配套，第3項的部分是講體育活動，並不是講智育及競技活動，也許這邊不適用，因為寫明了「體育活動」；或者也是自動適用？
簡單來講，推廣事業單位推廣電競社開始打電競這一件事，是否適用？
（笑）對，上班打。這邊是不無疑義，因為這邊用的是體育活動說法。其他4跟5都沒有講到體育，看起來是直接適用；這個是我的理解，不一定是對的。
瞭解，他們未來面臨的，橋牌或者是圍棋協會也都面臨，也就是他們註冊的時候，就要很清楚講是要按照新的規則。
也就是適用哪一些部分、哪一些不適用。
這邊都可以做逐字紀錄，大家可以編輯十天，如果編輯的過程中，如果大家都同意的話，就邀經濟部來看，等於這一場會議一開完，經濟部的朋友們會收到我們今天討論的過程，（經濟部）大家就會跟（在座）大家一樣有十天的機會對於這整個討論過程的意見，如果經濟部覺得需要跟利益關係人再作一次座談，或者甚至他們以上我們講的都不對，他們要提出一套講法，會請經濟部的朋友們提出要求；反過來，他們認為是補充說明，我們就把補充說明一併列在會議紀錄的十天公開版本裡。這樣文化部可以嗎？
如果沒有太多問題的話，具體放到不管是第8款或者第15款，或者其他別款，但是放在任何一個，這個就請教育部這邊最好能夠在十天內有一個初步的想法，不一定要變成核定的版本。
因為教育部有十天的時間提供他們的意見，所以希望至少有一個初步的狀況，這個就跟之前我們3次協調會的逐字稿一樣，之後會亮綠燈跟橘燈的區域，請文化部提供。
文化部的意見我會綜整，有要追加的話，也歡迎在十天內提出。
如果都沒有問題的話，還是一個小時結束，到這邊結束，謝謝大家。
📗 感謝各部會協調整合，教育部已同意讓電競技藝納入「運動產業發展條例」第四條第一項第八款「運動休閒教育服務業」的適用範圍，並以教育部為中央目的事業主管機關。 📗 也就是說，電子競技將等同於圍棋、紙牌遊戲等智力活動，適用「運動產業發展條例」之各項獎勵優惠措施，包括利息補貼及優惠融資等。 📗 針對電子競技納入「運動產業發展條例」後，現有可能提供的資源及其影響評估，教育部體育署也已初步盤點確認，內容如上。
這一張圖，是Rufus Pollock上次來這邊的時候，我們一起腦力激蕩出的一張圖。
當時我只是跟他討論一些設計上的考量，沒有提到消防署跟災防中心的兩個系統，但是我們在大略瞭解系統前提的情況下，無論如何還是設計出來了，今天我們只是再次快速走一遍，確定這個圖還是正確的。
EMIC以我的理解，消防署有權去主動通知大家、通知其他機關現在發生了什麼災害，然後災害的搶救狀況、前進指揮所的朋友上來登錄災情，這一條線的上半部是他的系統。
這一個系統是NEC在營運，但是後來因為portal.EMIC.gov.tw登入的部分performance不是很好，所以那部分請中華電去調校了。
總之，這個系統其實概念上非常簡單，就是集成跟所有災防有關的資訊，他們通通丟到DB裡面去，再給有不同權限的人登入之後，從後台去察看跟他有關的部分，然後分發給地方政府、民眾或者一些CBS之類的，也都可以訂閱說我想要哪一些特定的訊息。
他當然也有一些大眾可以看的界面，所以如果我們到EMIC網站的話，就可以看到他們事實上是有外面可以看的界面，不只是後端的東西，就是不只有管理界面。
這裡我們就會發現說，首先會用純文字，這裡可以看到，它也不是很結構化的資料，只能知道大概是怎麼回事。
然後下方會把所有相關的朋友們受到的訊息通通都po在這裡，我們發現目前收到了兩則，全部就這樣，這就是人類可見的部分。
反正就是長這樣。
沒有耶！其實這區都不是自動的，是人去上稿。
像震災，震災就很大了，不是嗎？同樣的也有補助、服務措施，所以簡單來講，就是維護一個非常類似hackfoldr的東西，結構上高達九成九相像的東西，而它的主要資料就是有時間碼的HTML。
當然在發生好比像颱風的時候，會有從氣象局那邊來的颱風動態圖，會把他收到的這一些hub裡面的東西，然後按照跟這個災害最相關的tag，但是我不確定是tag或者是income source去作分類，所以你會看到一個類似dashboard的東西。
總之，我們這次的business requirement是這樣的：上一次風災的時候，林全院長去視察，然後發現說道路斷掉的資訊、停水的資訊及停電的資訊，它沒有辦法接過來到地理資訊界面。
我們看到水電維生管線這一欄是空的，事實上當時真的有發生，只是不知道因為格式沒有接好還是什麼原因，所以沒有從台電、台水那邊接到圖台來。
那當然。
對。但是當時建立這一個系統，原因是希望EMIC系統是「N到1到M」的系統，意思就是台電也好、誰也好，只要到這裡就可以作必要的轉發，在發送的時候就可以說想要誰知道，或者是在這邊自己判斷這個有用，我還要另外轉發給誰。
實際建置出來之後就發現，那一些「N」根本不理它，自己還是去跟「M」聊，為什麼「N」還是繼續跟「M」聊有幾個原因：
第一，「N」往「1」的部分沒有那麼結構化，基本上就是你們看到的這樣，所以如果「N」跟「M」都希望要結構化資料，他們並沒有辦法說我的EMIC裡面包一個JSON，然後來收geotag或什麼別的東西，所以「N」就會直接跟「M」講了，因為EMIC沒有什麼用。
另外一件事是，從「M」的角度來看，有些會跟這一個「1」收滿多錢的，簡訊也好或者是其他東西也好，這邊都要花不少錢，才能發到「M」去，反而地方縣市的話，跟「M」有時候談到更好的條件，地方縣市的消防局這些，當然是最大的「N」，當最大的「N」都已經直接跟「M」結合了，「1」的意義就變得非常小，對「M」來講，不接這個「1」，也接得到「N」。
總之，「N到1到M」，我上次問說如果把這一個轉送的服務整個抽掉，會對下一次颱風有什麼影響，消防署的人想一想說沒有什麼影響（笑）。
這個所謂的「災防雲」，就是message bus，所有關於災害的資訊都在這裡，所以要做任何事後分析跟ETL，這邊等於是最全的資料。
但是事實上不是，就是遭到了bypass，有些資訊來源自己先對外，之後再來EMIC登錄。
院長上次不是很滿意，因為發現台水、台電的「N」沒有完全接過來，而且最大的問題就是，有接過來的部份，還要自己在腦裡看著地址去還原到圖上，就是跟颱風動態圖完全沒有對應。
這是有一個圖台的，理論上在後台是可以用疊圖的方式放上去，但是從民眾的角度來看，並沒有任何類似這樣子的東西。
以上是EMIC的故事。
不是，EMIC一定要有啦！只是「N到1到M」的訊息轉送那一部分，一次災害，現在通常都是送個位數，有的時候根本沒有送到「M」。
這個是我們下午會知道的事情。
可能還沒有那麼快討論這個，只是先理解實際狀況。
總之，這邊存在另外一組人，NCDR，他們自己會寫程式，不需要找廠商，所以他們就常常收到地方政府的一些需求……
這是首頁，然後按到災害情資平台，榮獲金質獎……
不對啊！在desktop上可以按啊！對不對？我在desktop上有按進去啊！明明就可以啊！
好，很好（笑），沒有關係，我們手動打。（輸入）有了，明明就有了。
所以就是有一些這種預警的，然後本來是所謂的監測模式，好比像月降雨統計或者是什麼颱風路徑統計，有的沒有的東西。2月沒有颱風之類的，它有一些這一種東西，還有一些降雨指標，如果颱風來的話，會有一些警戒、土石流這一些東西，在災害快要來的時候，就是地方會連到這一些網站上去看，但是我們就發現幾件事情。
第一個，圖雖然看起來滿專業的，但是在這邊仍然是不同的tab，所以如果是一個縣市的話，進來就是要cycle through一些tab。
我們從這邊可以看出來，至少他們很會寫程式，當院長說我們現在要把路況或者是什麼東西疊到這一張圖上才有意義的時候，從消防署的角度來看，他們現行的EMIC系統很難直接implement這一件事。
所以我現在的想法是，他們的後端都還是各自的後端，他們的KML或者是他們的圖台至少是用一樣的底圖了，如果這樣的話，理論上只要給經緯度、座標或者是任何geodata過的message data，這兩邊的呈現應該是要相同的，如果不相同的，那就是圖台的問題。
所以只要EMIC這邊先把他的訊息匯出成data package，然後讓NCDR consume，這樣理論上對於公眾來說，NCDR的前端應該可以完全取代EMIC的前端，那EMIC的前端可能就是重導向或者是一個Reverse proxy，或者隨便怎麼樣，總之你來EMIC.gov.tw的時候，你看到的是NCDR寫的前端。
至少在套圖以及基本開發上面，NCDR的前端能力應該是沒有問題的。
