政府資料開放平臺修正建議(持續募集中!!)
Leo Cheng大家若對本修正建議有任何意見，歡迎使用comment功能或是直接在文件上提出建議!!
政府資料開放平臺(以下簡稱本平臺)現況基本說明：
- 定位為「全國政府機關構Open Data入口網」，提供便捷易用的單一入口。（本平臺並無保有資料資源）
- 可對各機關所屬資料集的提問機制［我有話要說－可提供API介接］
- 可提出政府資料需求的入口［我想要更多－由本平臺維運團隊依需求分派不同機關］
- 本平臺搜尋引擎搜尋範圍包含＂資料集名稱＂、＂資料集描述＂、＂資料集提供機關＂、＂關鍵字＂等。
有關資料品質的部分將挖另一坑討論，coming soon...
「我還想要更多」這部分，不知道有沒有機會讓各部會管理者分派予權責機關回復，也許能有效即時更新回復內容。
「我想要更多」這塊是指讓部會管理者直接指派特定帳號回應嗎?
我想要更多中若狀態為研議中的話,是否不予理會呢?因為還是會收到信件通知
原則上這個只是提醒囉
略為爬文之後，我發現我的幾個想法好像無法歸類...，所以我就先寫在這裡。如果管理者看到，有適合的段落，可以幫我放進去。
身為資料提供者，我覺得應該要提供批次修正的功能。以政府機關來看，各單位開放資料的承辦人其實來來去去，磐石單位流水兵，更不要說各資料集的負責人調動之頻繁。因此是否可以提供資料提供者資料批次修改功能，比如說聯絡人或負責人的資訊修改，等等。不然有些單位一口氣要修改數百筆資料的時候真的會升天。
另外關於使用者，我也有話要說：目前來看，很多資料的單位與字詞標準都是有相當差異的。比如說45,000可能有人以阿拉伯數字寫就、有人會寫成4.5萬、也有人寫4萬5千。就算是用阿拉伯數字表示，也有可能有人有用comma有人沒有用。又比如說城市名稱，有些人提供資料是用台北市、有些人是用臺北市、有些人用臺北、有人用台北。這些其實都是在說一樣的東西一樣的地方，但在做統計的時候就會產生標籤不一致的狀況。所以我在想有沒有可能提供自動轉換功能，使不管哪邊提供的單位字詞可以進可能的一致化來方便使用？不過這個可能就到了資料品質的部分...，要另外開板嘛？以上。
感謝，等下簡報完找時間整理。
資料品質有另開，但我還沒整理完...
上面第一段指的是批次修正功能，目前解法會建議採用批次上架的方式處理；
關於第二段的部分，這屬於領域資料標準化，目前這還在等各標準主管機關
1.覺得目前opendata平台主要是針對民眾與加值段的服務，如果後續年度是否也能加強「平台」後段使用者的教育?實在是許多業務單位承辦人來去頻繁，若能從平台下手直接讓操作的各資料來源單位承辦人能快速清楚了解相關規定、基本開放資料格式、樣態等等，也許能幫助異動頻繁的各「業務單位」更容易快速上手，可能也能對於從源頭的資料有一定程度上的改善。(實在是現在的教育訓練多為單位資訊人員去，能否有效傳達到業務承辦人那邊都令人擔憂)
2.另外像「台北市、臺北市、台北」等問題，若於資料內容本身即便相關單位有建立一致性的標準，但感覺這些標準目前也多囿限於各領域資料內；只是跨領域的資料一致性(如前面的臺北市或座標等等)就難以清理、整合。即便屬於各主管機關領域內資料，就目前了解現況各部會亦無完善之相關法規強制要求各地方主管機關提報資料，也是造成資料整合的一大困難，也建議國發會可以思考看看並協助各部會。
3.建議在後台部分也可以多以使用者角度思考，多以下拉式選單、範例文字等方式輔助，讓metadata部分就能先具有標準化的形式。
其實我後來想想...，覺得最困難的是所有資料只是透過這個平台分享，實際上存在於不同機關所控管的空間裡面，在資料統一上可能會有問題。這個不知道該怎麼解決？由主管機關開發一個程式給所有人用，然後每個人上傳前先run過一次該程式以產出統一字詞版本的文件之後再上傳...，這種想法會不會太厚工..
不知道這樣的想法可行性有多高，單位同仁有提到若是能從採購的角度下手，在各單位於新年度重新招標時及能建置可結構化的機器系統，也許有機會能在不造成業務單位同仁負擔下，自動化的直接產出結構化資料，同步透過標準制定一致性的去調整各部會甚至地方政府的系統.....這樣即便承辦人來去更迭，也不致造成品質上的落差(可能也不需要重複教育)，亦可逐步弭消資料內容不一致問題?
突然發現這裡還有沒回到的...
系統功能面：
- 建議刪除預計開放資料集，改以「（各部會 / 縣市政府）盤點資料集清單」替代，提供與"我有話要說"一致的民眾意見回饋管道。
審計部的異常稽核來自既有預計開放資料集的"逾期未開放"，此部分日期計算功能是否有必要保留?
如有任何意見歡迎在這裡直接提出討論，謝謝!!
1.預計開放資料集、乙類資料集清單多與各單位資料盤點表有重複情形，建議保留一項。
2.若仍保留預計開放資料集項目，原屬預計開放資料及之期限、內容、資料集檔案名稱等，若有異動仍需保留更改機制。
所以目前功能是以僅留下「（各部會 / 縣市政府）盤點資料集清單」做考量，但裡面的欄位將會需要一致訂定。
- 建議資料集更名(原暫時下架)、永久下架權限下放至
行政院所屬二級機關 / 地方政府部會管理者。
將本平臺各部會 / 縣市政府更名中、永久下架資料集自動產生一個清冊放在一個資料集內?
或是 http://data.gov.tw/node/6564 增加一個欄位標示現在狀態(停止更新/下架/etc.). 不過感覺若是永久下架, 不要放在 6564 比較好
嘿阿，下架部分若是跟現行混在同一張表應該是不太妥...
20161011 update: 比照 http://data.gov.tw/node/6564 建立另一個資料集下架清單，並於備註內讓各部會管理者於下架時加入下架事由（採用介接機關就無解了... 但已下架的仍會出現在清單內）
下架權限下放後，原則訂定要不要配合修改??不然下方後原則未修改也可能是淪於形式。
參照 [政府資料開放進階行動方案] 資料以不下架為原則 ，原則並無改變，此部分用意主要係簡化程序，且國發會實際上並無審酌他部會資料之能力。
所以現行「資料集下架申請流程」也會一併移轉至部會管理者嗎?即便部會管理者審核下架機制是否也有相關通報機制至國發會統一列管?
是哦，目前規劃的確是回歸部會管理者，國發會不會有所謂的「列管」，而是像前面說的以系統自動化建立「政府資料開放平臺下架資料集清單」，讓所有使用者可以得知哪些資料被下架。
- 下架公告改由資料提供機關自行po文介面，並於公告7日後自動下架。(介接機關不受此限?)
- 提供CSV / JSON / XML互轉工具
個人傾向： 參照「政府資料開放平臺資料集清單」（http://data.gov.tw/node/6564），建立「政府資料開放平臺已下架資料集清單」，並設計每日更新之自動化流程，於下架時填列之事由可接露於清單。
有關資料集下架的通知：目前是以「政府資料開放平臺資料集清單」來告知民眾，但單位中許多人反映民眾在資料下架後不會特地去查找這個資料集，只會單純認為是資料集連結出錯(除了留言外可能會透過機關的官網反映….)，而且目前政策傾向把民眾導到這個平台使用，公告作業還是在平台上明顯處進行為佳，也許可以多加一個描述欄位「資料到期時間」？或有其他更妥善的方式做告知(要是有會員制能自動email通知會員就更好了[補充:會員制的目的是希望能提供更優質的即時資訊服務])。
下架目前並沒有對於民眾的通知，應該說這裡分成兩塊：
1.在本平台手動上架然後申請永久下架的會走公告：http://data.gov.tw/node/35370
2.介接下架則無聲無息。
如果像前面所說的只用連結的話，那我們怎麼公告應該都是沒有用的。
另外，採用介接的機關若是資料下架的話，亦無法帶出公告或告知（通知訂閱使用者是做得到）
因此我個人建議以「政府資料開放平臺已下架資料集清單」揭露應該會是最簡易明確的方式。
上傳CSV自動產製另外兩者?
有地點屬性的資料提供 GeoJSON
資料如果有分多個時期，合併成單一 CSV 檔案，例如台北市違反勞基法事業名單
民眾可上傳重製後的檔案，分享給其他人用，解決政府無能力改進的問題
民眾重製後的檔案如果有誤，提供勘誤管道
民眾重製檔案的定型化免責聲明，避免資料有誤時可能產生的法律責任
哈囉，請別介意我一邊回覆，請繼續
1.地理圖資部分我比較不熟，目前除了內政部TGOS外，於本平台提供的地理圖資多數以壓縮檔的方式呈現，內容主要為KML格式，此部分平台能給予其如何協助為宜?
2.資料集不當切割情事，目前本會立場僅能道德勸說... 於內政部所屬機關部分，受到"政府資料開放進階行動方案"資料集"數量"規範，常使機關改以月份、區域作為資料集分割的理由，此部分已逐漸限縮，但仍無可依循之規範。（我個人認為數量要求應鬆綁，但我一個人無力XD）
3.民間回饋部分請參閱"民間資料集回饋機制："，目前規劃會採分區但格式與既有資料集詮釋頁類似的方式呈現，關聯部分尚在思考是否能達成雙向鏈結。免責條款是一定要的，不然公部門勢必反彈XD
請參考 https://github.com/virus-warnning/taiwan-anthropogeography-data/blob/master/categories/unluckylabor/unluckylabor.geojson
這是台北市違反勞基法事業名單轉 GeoJSON 的成果
轉檔能力不足或是無法要求地方政府的部分，可以利用民眾重製的能量解決，不一定要採用大政府主義
中央可以審核民眾上傳的資料，用總量管制的方式提供合理的上傳次數
我了解了謝謝
政府是否需要審核民眾資料這點目前尚有爭議，目前參採法國OD的方式是完全不審，不知道有哪個地方是採用審查制? 某些角度來說我是不認為政府有權審查(誰來審? 業務主管機關? 國發會維運平台? 感覺都不合適)，但需要刪除惡意內容。
1.可不可直接在平台宣導or建議相關轉換工具??建議優先讓資料來源單位專注產製正確且品質佳的資料為優先考量。若採上傳檔案後自動產製的方式，無論是資料來源端及平台這邊都很難再詳細檢視轉換內容。
2.評估設置民眾專區或於各資料集項下提供專欄，讓民眾可以將自己重製後的資料、或加值後有價且願意分享的資料公開。
1.目前的確已經規劃CSV / JSON / XML轉換工具，並且預計於本平台上架時可提供僅上傳CSV後自動產製其他類型格式的規劃。當然，這並非強制功能，如須檢視就視資料提供機關而定。
- [後台] 建立結構化文件自動讀取建議欄位置入「主要欄位說明」。
- [後台] 提供基於各部會 / 縣市政府（含所屬機關）自行查詢「資料集品質評鑑結果」（可機器測試項目）
- [前台] 將各部會 / 縣市政府（含所屬機關）之「資料集品質評鑑結果」定期更新於前台。
- 提供手動上傳、批次上傳、API介接流程說明文件。
- 系統收發信測試 (?)
- [後台] 可由後臺匯出權責範圍內指定期間上 / 下架資料集詳細資料。
- [後台] 可由後臺匯出權責範圍內資料集瀏覽 / 下載次數詳細資料。
- 有機關建議應增列「主題專區」，建議可由主題式標籤達成目的(?)。
彈性式主題標籤，提供後臺管理者主題標籤設定功能。資料提供者可於資料集上架時，於標籤列點選適合之主題標籤。
- 提供搜尋引擎優化(SEO)與社交網路優化(SMO，含og-image功能)
- 提供民眾勘誤管道，以利回饋 (各個版本) 資料品質。
目前這項是放在各資料集下方的"我有話要說"內，但回應品質就會隨原資料提供機關的積極度而定。
請教有更具體的建議作法嗎?
機關積極度及回應內容難以長期追蹤，尤其是許多業務單位更不了解opendata的一些規定、運作等(可能也無從了解)，是否對於資料提供者或回復單位可以建立回復類型建議方式，或提供回復錯誤態樣之類供願意耕耘的業務單位參考?
國發會的立場是可以蒐集一些範例，但感覺不同資料的回覆方式應該是差異很大...
或許應該來加入JOIN平台的小編訓練~
資料集詮釋資料標準規範（ http://data.gov.tw/node/18252 ）
- 建議增加預留欄位（for 整包下載?、etc.）
- 考量資料集內資料資源資料型態不同，為了將來提升資料品質導入Data Schema，各資料資源之欄位描述及定義：
- 方案一：沿用既有機制，將資料資源來欄位載明於「主要欄位說明」(fieldDescription)，要求同一資料集下資料欄位應有一致性欄位。
- 方案二：採用【資料集詮釋資料標準規範】內「資料資源描述」(resourceDescription)，或「領域別詮釋資料參考網址」(metadataSourceOfData)，可達成各項資料資源欄位詳細描述。
- 在【資料集詮釋資料標準規範】定義的是「資料存取網址」及「資料下載網址」兩個欄位，結果在系統上卻變成：
個人建議主要欄位為概述性質，細部資料說明若以說明檔(*.txt、*.ini)提供，建議放置於【資料集詮釋資料標準規範】。
- 方案一：依據規範將「資料存取網址」及「資料下載網址」分為兩欄，並採擇一必填。
- 方案二：資料資源網址僅須維持單一欄位即可。（資料資源形態為 檔案 / WEBSERVICES (含API) 已於檔案格式勾選，建議修正規範）
需要增加欄位描述資料集更新方式(ex. 有整包更新含歷史資料的、有不斷追加新檔然後砍舊檔的、有只留最新版本其他通通砍掉的, etc.), p.s. 因應非結構化資料, 提供一個選項 "其他".
新增欄位的部分會需要修規範，不過這塊實作下去真的有人會選嗎...(遠目
政府資料開放跨平臺介接規範（ http://data.gov.tw/node/18254 ）
p.s.主要供政府機關資料開放平臺介接使用
- 單一Publish規範。
- 原有Harvest機制預計106年底落日。
API匯出建議：
- 比方說列出 files:[{type:"xml",url:"http://wwwxxxxx}]
- 而不是 urls:"url1,url2,url2",mimetypes:{type1,type2,type3}
民間資料集回饋機制：
- 本平臺維運政府不干涉審核，僅刪除惡意、廣告與資料開放無關性質之訊息。
- 本平臺不額外提供資料儲存空間，僅以記錄metadata為主。
- 民間上傳資料集可填列其相關之政府資料集。
希望能上傳自動化檢查程式，讓民眾自成資料提供者與審查者的生態
請問這塊是檢查誰? 民間資料嗎?
還是說提供一個通用性的上傳介面讓想檢查的人自己丟?
比對民間資料轉檔後是否和公家單位原始檔有出入，最好限定程式語言，讓系統單純一點，希望限定 Python 3.x 不然 Ruby 也可以。
有審查程式的資料，希望能另外給予標記，讓民眾能識別這樣的資料可能比較有品質。
審查程式上傳後，透過 Lint 工具檢查審查程式是否存在資安風險，正向表列可用的 Library。
請問上面這裡描述的比對部分，是由平台提供工具? 還是平台平台提供介面? (介面的話代表要能輸入對應的官方資料資源? 又若有檔案整併情事感覺設計上會很複雜?)
還有，回歸前面說的，審查應由誰來審查為宜?
審查用民間提供的審查程式去審查
審查程式用 Lint 工具審查
審查平台包含 Lint 那些的由政府供應
不好意思，想確認一下這裡討論的標的是民間資料集的部分對吧?
對
嗯... 那再請教一下
問題1. 對民間資料集的審查是必要的嗎?
問題2. 前面的意思看來是讓民間自行以Lint工具進行審查?
問題3. 在本平臺並無存有資料資源的前提下，應如何審查?
回答1. 民間資料及審查非必要，只是一種提高可信度的手段
回答2. Lint 工具由政府提供，主要是防止惡意人士植入攻擊程式
回答3. 資料來源可以貼個連結表示，如果能用族譜的方式表達更好
瞭解，也就是說政府釋出工具讓民間自己去玩?
族譜指的是樹狀圖對吧?
是的，政府給生態環境，民間自由運作，每年調整一次規範，規範宜少不宜多，以不妨礙言論自由和二次創作為原則。
是的，族譜是樹狀圖，可以讓人知道創作脈絡，高度重製的作品需要加以標示，因為通常會有較多的錯誤。
二次創作或 N 次創作一定會有錯誤，但是要先求創作而不是先求正確性，如果稍有錯誤就搬出偽造文書罪，會打擊創作動機，這是我認為開放資料再利用最大的阻力，但是重製的作品可以要求強制標示資料已經過重製，就像投資基金的公開說明書一樣。
目前是連規範都沒有，看來免責條款的部分需要下點功夫...
感謝大大的意見!! 我會盡可能在RFP內埋梗!!
吃完飯後想到一個問題，既然沒有保有資料，那經工具檢核似乎依然不能掛標章?
經工具檢核只代表有檢核，不代表資料一定正確，其實即使是人工產出資料我相信一定也會有錯，但是經工具檢核的資料，可以標記一些資料品質標章，例如格式一致性、欄位完整性、資料正確性、UTF-8 等等 ...
主要欄位、編碼等目前在政府提供之資料集係由資料提供者自行填列，再搭配目前撰擬中的資料品質評鑑檢測程式進行；惟資料正確性這點好像工具做不到吧XD
另外，前面擔心的是，若是有人拿資料上來經過檢核了，在相同路徑下被抽換檔案，這部分好像攔不到?
初期發展應該先興利而非防弊，如果要防弊需要用到很多資安技術，像是加密、數位簽章等，但這些技術不是目前公務員可以負荷，只要上傳資料採用實名制，每人每天限制一定的上傳次數應該就夠了，核心精神是鼓勵公務員多分享資料，民眾多參與重製資料與再利用。
「民間反饋意見」可評估分類，如資料集內容勘誤、建議新增收納資料欄位、資料內容詢問or單純給予資料來源單位鼓勵...。
目前針對個資料集的意見回饋「我有話要說」的確已經有這個功能囉，只是意見回饋這件事情要如何督促將會是另一個問題...
不同意見類型會有相對須回應的部分嗎??其實像是肯定與鼓勵這類是不太需要回復的訊息。
這類型是用來快速分類用的，並沒有制式SOP哦
肯定與鼓勵在本平臺列管範圍已經排除 (無須回覆)，但這是對於資料提供者的一種鼓勵，建議保留。
- 免責條款。
資料集評鑑機制：
- 針對自動查核項目，開放各機關自行使用查核，以利預為改善。
哈哈... 資料集品質評鑑這件事，原先的規劃本來就是供機關自行評核用，但一到長官手上就變成一定要評分的機制啦...
理解。謝謝了。
1.請留意評分立基不一狀況(如資料集數量)，避免單位為避免影響評分造成資料集內容、品質不佳，產生同一資料集下濫竽充數；或可能減少資料集上架以避免評鑑分數不佳。
2.圖資內容是否有納入評鑑機制??
3.各單位資料集上架時是否可提供相關檢核機制，以提醒並保障各項資料集上傳之品質。
4.清楚定義「資料集品質」查核範圍，是單包含資料集格式、metadata等，或需深入到資料內容(但非資料主管機關難以查核這部分)???
5.目前試辦單位皆多以資料集狀況良好的單位為標竿合作對象，建議未來推廣須配合提供相關教育訓練、諮詢服務，以讓各機關可順利推廣。
6.於後台開設資料評鑑專區，並提供各機關標竿案例?
7.ODF-CNS15251實施計畫中有明確說明開放性檔案之定義及格式，其中亦包含PDF格式，此部分後續評分的標準為???
1.目前是以資料資源並以百分比的方式進行計算，不過您提的濫芋充數的部分目前的確值得思考，例如同一資料集下的CSV同時提供 XML、JSON格式是否允當? 對於以API / Webservice提供的是否會造成不公平?
2.圖資內容目前理解以KML,SHP之類的方式，並且常以壓縮檔的方式進行提供，原則上當然包含，但要如何對於圖資檔案進行正確評測的確有造成困擾，也希望能有更多朋友能提供建議。
3.上架時直接檢核嗎? 可納入，但仍要考量採API介接 / 批次上架等態樣。
4.資料集品質評鑑初步將以草案內容的七項指標
(1.)資料資源連結有效性
(2.)資料資源可直接下載
(3.)資料屬結構化格式
(4.)資料編碼符合詮釋資料編碼型態
(5.)資料集詮釋欄位之「主要欄位說明」與資料資源欄位相符
(6.)資料更新時效性 (人工檢核)
(7.)民間回應錯誤之回復效率 (人工檢核)
人工檢核的部分其實我個人是想盡量排除，若是有能程式化檢測的檢驗方式也歡迎大家提建議。
5.感謝提醒，這塊將會先以易懂的改善範例優先提供，再搭配教育訓練與諮詢進行。
6.同上。
7.Open Data跟ODF-CNS15251有不小的落差哦~
即便是ODF中的文件格式 (.odt) 是屬於開放格式，但未必屬於結構化資料 (要滿足資料開放三星等而言，其需要同時滿足前面星等之條件)
回歸資料使用面而言，拿到一份"PDF"的時候，除了截圖跟手抄之外，還可以如何取用裡面的資料?
目前各單位資料上下架是否存有須單獨以人工上架or自動介接情況?
基本上一個機關僅會有人工上架 / API介接擇一的情況，目前規劃並無併存可能。
btw, 品質評鑑真的應該另開主題的...
另外補充，平台不提供額外儲存空間可能也是會影響品質評鑑上的一點。當然目前平台只提供資料集的描述，下載仍是連到各機關的儲存空間。但只要知道儲存空間的連結，民眾會直接連結到儲存空間取用資料集，使得平台上的下載次數失真(例如每日更新的資料集民眾並不會再特地連到資料開放平台點擊…..)，如果未來以下載次數列入開放資料集品質評鑑項目的話，會有點擔心，建議在這部分再審慎思量。
目前沒有加入任何瀏覽或下載次數的KPI哦，性質不同的資料集使用方式本來就不一樣，至少可以不用擔心我不會這樣訂。
5.請問歷史資料的更新頻率,若改為歷史狀態,機測這部份是否會略過.
詮釋資料中的主要欄位,目前還有看到欄位是這樣標示的: 少部份 A/B/C 用斜線表示,大部份是A , B , C A、B、C方式,而非3. A,B,C A;B;C A.B.C等等.如果有斜線表示的話可以嗎?
更新頻率尚未納入機測哦
主要欄位分隔方式目前採用主要會是半形逗號、分號，以及全形頓號，斜線的話我想可能會跟部分欄位說明造成衝突...
可以再提出討論看看。
我發現今天我們資料集的主要欄位還有人有" "字串方式描述.,看來真的要統一一下,http://data.tycg.gov.tw/opendata/datalist/datasetMeta?oid=04d16b23-bef1-40fe-a698-40cbab5d01cb
leo幫我看一下這筆 http://data.tycg.gov.tw/opendata/datalist/datasetMeta/resource?oid=5abd3514-a6c9-42c3-b59a-6815f3a218ad&rid=d96b4951-fe37-449a-89a4-2d251921a724
主要欄位說明,可省略id嗎?
我覺得沒有省略的必要，這樣或許有助於同仁理解甚麼叫做"資料"
其實我有再擔心這樣的欄位填寫方式是否足夠？
以＂桃園市政府機關通訊錄API＂來說，這頗為類似JSON格式，似乎沒什麼不好？
其實是因為ID這個欄位是CKAN系統他自行產生的,所以這個在詮釋資料的主要欄位也不能省略嗎?
理解，判斷邏輯的部份我們在討論看看該如何處理。
因為我們系統之後更版新的之後,也會有一欄是自動產生的序號,通常該欄為_id,另外有看到國發會前台-資料集詮釋資料標準規範.pdf ,提到建議用1. {"accrualPeriodicity":"每日"} 2. {"accrualPeriodicity":"每 10 分鐘"} 3. {"accrualPeriodicity":"每年"} 4. {"accrualPeriodicity":"即時"} 5. {"accrualPeriodicity":"不定期"},如果使用每週,每季,每半年,機器是可讀取的嗎?
以下這3個連結點:
http://data.tycg.gov.tw/opendata/datalist/datasetMetaPreview?oid=990f841c-29f2-4547-8669-2acef97eff73
- http://data.tycg.gov.tw/opendata/datalist/datasetMetaPreview?oid=deda0ea0-51c2-46b8-9e10-c0a063351c6c