這個部分有沒有人在裡面，或者是這個流程有沒有人要再結合隱私評估，像IRB等，那是未來的發展。國發會第四階段的政府電子化，是以這個當作區段。
這個要講清楚的是，現在有一個很固定的流程，每一個要求提供資料、品質改善及格式調整都會分案到每一個部會的資訊小組，每一個資訊小組就是三個月開一次會，這邊的每一份資料是國發會才有的，那時要求把這個變成開放資料，像追PChome的訂單資料一樣，現在是小組討論或決定釋出與否，這個流程是已經在run了。
這個是財政部的名單。每一個部會現在按照編制都有這樣的新制，裡面也有各處處長的成員。
這些要求本身也都是open data。
他們的想法是民間如果對公部門有任何要求的話，就是往國發會提，接下來國發會會分案，也就是按照要求的性質，分到政府資料開放諮詢小組。32個都會分到。
我想很快速處理，目前處理這樣的東西，其實在國發會的底下是資料開放諮詢小組。
從來沒有，這是第一次。
這當然是可以說服人的說法，兩相權衡之下，或許可以遮掉欄位，讓原持有人也無從識別？這是目前的幾種講法，我不知道你們要如何進行這件事。
我的意思是，就像其實剛剛您講的非常好，歐盟在2017年說要培植去識別化、打馬賽克，其實這個是非常hot的研究主題，因為自從safe harbor廢除後，所有server都要在存在歐盟當地，都要在這裡計算。
如果特種個資那條沒有施行的話，實務上很容易說有增進公共利益，就開放了...
目前還在CNS計畫的附錄當中，但能不能落實，也要看上位價值的概念宣示。
在vTaiwan討論之前，這些規範還沒有完成。
代碼化不能算作去識別化，但不知道為什麼，之前沒有去建立這個肯認...
是的，就按照內文去連結就結束了。
像是把所有的身分證字號的欄都變成Hash，這個問題很大，如果這個Hash到別的資料集也是相同的值，可以連結攻擊...
所以用臺權會的講法，就是必須要鑽漏洞，也就是以統計及學術研究的必要，按照目前的個資法來開放。這個時候的目的外利用，必須要無從識別當事人，但現在的問題是何謂「無從識別」？這裡其實是按照不同國家、不同法系甚至是不同的利用方式有不同的標準，但在我們討論這個建議之前，原本是「不具技術者無法識別」就可以了。
現在要推open data，往私部門的open data的特質，就是會一直用目的外利用來做統計，因為大部分sensor並不是為了open data設定，而是幾十年前就設定好的。
所以一開始就聲明要做這一件事，就是目的內利用，這件事就結束了。
需要推動的，是去識別化標準的認定。也就是說，目前個資分成目的內利用，像是今天逐字稿寄給大家。而目的外的利用是，我沒有講要寄給逐字給其他人利用，後來才想要利用。
這個架構至少是美國、歐盟、紐西蘭都有使用，但在臺灣一直沒有辦法推的主要原因，是對新個資法的共識沒有建立起來。
至於技術標準，其實都已經有整理出來一份，之後可以整理給大家，如果前面的價值有落實的話，我們實務上才可以很容易做list，也就是現在是統計資料，好比是ETC的資料，如果要拿去給所有的人使用，這就變成open data，就要讓原持有人沒有辦法識別，這也是處理完幾欄幾列就可以解決的一件事。
我沒有要爭辯這個價值，而是這些價值沒有落實，要如何落實。
另外，新個資法是抄歐盟之前的架構，但他們的三大價值是醫療、研究及歷史保存，不知道為什麼到臺灣就變成醫療、衛生及犯罪預防，我們可以看到國家的價值並不是完全一樣...（笑）
如果能夠把特種個資施行的話，問題會少一堆，但這後面有太多的利益要處理。這是一件事。
現在完全卡住的，是特別敏感個資的部分，除了醫療衛生及犯罪預防之外，這就是健保案最核心的那一點，現在是因為現在的政府說這個太難施行、不施行，所以健保個資利用不算違法。
我們對民進黨執政的一個檢驗，會是你們的法務是否能把特種個資的部分實施起來？
這個是vTaiwan的十二案之一，有寫一份建議書。
在資訊科學上，可以想成是CRDT（Conflict-free replicated data type）。大家編輯每一份文件，也就是事後合併是沒有成本的，目前電子化功能系統，如果是用剛性結構的欄位，只要有一個欄位分出去就沒有辦法合併，這個是很大的差別。這跟課發會把剛性課綱改成柔性課綱的方向有一點像，但今天沒有要講這個，所以就先到這裡。
也就是說，如果說規定這個世界上只有十個tag或者是一百個tag，這個是哪一些的子集合或者是母集合，事實上根本沒有人會使用。相反在推特上把一個流行的hashtag呈現給大家，大家就會自動自發把同異字等等建立起來，這等於是你要求大家都用，但用的這個東西是最基本的，也就是彈性夠，以致於任何人可以分支出去，不影響未來合併的可能性，這是盡可能翻成中文了，這就是沒有衝突的資料結構，這樣的話，我覺得長期看來才有希望，而不是又講了火星文。
所以後來我們在資訊設計，常用的是「弱聯結」或者是「弱結構」，所謂的「Folksonomy」，也就是大家開始繞著他幫他加標籤，變成是半結構化semi-structured data。也就是我現在有一份資料丟出來，但容許讓任何人引到別的資料去，這樣看起來雖然沒有那麼漂亮，但是比較有彈性。
我只想講一個概念：剛才說要訂一個方式，給所有的人訂一個統一的格式，這是非常關鍵的，但如果那個格式是樹狀分類學Taxonomy，那樣就一定會變成做一套分類給上面看，自己按照實際業務需要做一些自己的附加Excel檔，因為沒有辦法跟他實際需要的東西用上。
因為我們都是data-centric API design，可以在上面做出更多的應用來，光是microblogging就把每一個站的排班表等等就等於是他們的資訊盒，像Wiki是很後來才用，這就是變成是他們無可取代的訊息匯流排。
但如果一些少數的人在裡面，開始找到一個能夠把這個東西丟上去，跨部門來用... 像英國的一家鐵路公司SE Railways就是用裡面最簡單的microblogging的功能，也就是在臉書上或者是推特上做每一個班誤點的通報，他們就趕快用hashtag的代號，這就是非常便宜的方式。但是這些資料也算是公司機密，所以不能用推特作這件事。
如果是above the flow of work，一開始做一套，後來又做一套，即使大老闆說要這個、顧問費隨便算，一年之內一定解約，即使畫面再漂亮都沒有用。
我們在導入的時候，在09年的時候我們寫了一篇分析報告。導入成功跟失敗有一個很簡單的看法，這個系統進去的時候，如果能讓他們的業務中間生出更漂亮的東西，我們叫做in the flow of work，就是在工作過程中使用的東西，就會成功。
公務員當時常常會上開心農場，雖然本來沒有FB，但為了要上開心農場，所以學會上FB。我們建了一個內網，同時配上Wiki，所以大家互動的紀錄就會慢慢把懂的事情留下來，大客戶是醫療相關或者是國防相關，澳洲政府也是早期的用戶，都是比較在意intranet隱私的，不然他們就是用FB或者是google就好了。
就是這一家公司賣給另外一家公司。當然還在跟蘋果合作，不過那個是興趣，這個是2008年我進去跟發明試算表的人當同事，我們那時候做的就是FB for Work或者是Google App for Enterprise的事情。
我自己的想法，我在退休之前，我2013年退休...
是，這講很多次了。
兩個人來寫都一樣的內容的話，這不會受著作權保護。
我的意思是學歷不足，就要繞好幾層...
當年在自由軟體鑄造廠，我是印表機耗材...
g0v的模式主要是建立在兩套系統上，就是共同編輯的文件和試算表系統。也是大家不用學習就會的東西，因為跟office長得差不多，可以留下足夠多的資料，讓大家去貢獻一點時間。
這邊串起來就好。
對，因為現在符合這個標準沒有什麼好處，未來是如果符合標準就會自動有視覺化等應用。
如果有中央標準，通常比較沒經費的縣市就會使用。不然每一個都一套，簡單講就是這樣。
歡迎挖坑！
但Whisky講的是numeric data，sensor產生出來的東西就是給機器看的，人不太能夠直接賦予意義，就會有數據到資訊的處理需求。
剛剛我們定義裡，Whisky所說的就是我剛剛說數據的部分，我剛剛特別通常講的，是文字資料一開始是給人看的，所以g0v做很多事情，讓它也可以給機器看。
大概先講到這邊，有沒有人對定義或者是框架要討論的？在進入實體之前？
