政府開放資料品質檢驗機制
編輯歷史
| 時間 | 作者 | 版本 |
|---|---|---|
| 2014-05-19 21:42 – 21:42 | r4018 – r4023 | |
顯示 diff(16 行未修改)
*可建立常見/推薦格式列表,比方說 csv, json, shp, topojson, px, png, etc...
*小小分類一下:
- *表格資料:建議使用 csv
+ *表格資料:建議使用 csv, tsv
*圖片資料:建議使用 png
- *文件資料:建議使用 json
+ *文件資料:建議使用 json, txt
*....
**程式可讀性
(176 行未修改)
|
||
| 2014-05-19 06:54 – 07:07 | r3856 – r4017 | |
顯示 diff(132 行未修改)
下方開始將上方的討論總結
- *g0v 社群建議針對政府開放資料品質檢驗應注意之要點
+ *g0v 社群建議政府開放資料品質檢驗應注意之要點
導言
(57 行未修改)
- *透過民間力
+
+ 社群針對開放資料品質檢驗所能提供之協助
+ 由於零時政府並未組織化,民眾參與均為自發性、志願性,其產出並沒有強制力或約束力,因此除非找到個人願意提供協助,否則無法對政府單位提出實質上的承諾。然而目前有 g0v 專案計劃要建立開放資料整理平台( http://data.g0v.tw ),基於開放源碼的出發點,屆時可作為開放資料整理的示範網站,供政府參考。
|
||
| 2014-05-19 06:54 | r3855 | |
顯示 diff(197 行未修改)
|
||
| 2014-05-19 06:47 – 06:54 | r3773 – r3854 | |
顯示 diff(105 行未修改)
*有鑒於政治獻金、建築執照等資訊都是紙本掃描,這類形態的資料是否可以專案處理?全國性的清查此類資料,建立資料轉換小組,利用網站透過群眾外包或是雇員將資料建檔。
*讓一般民眾傳達意見的管道
- *除了駭客之外,建議有一個管道,讓一般民眾提一些意見。廣義的開放資料
+ *除了駭客之外,建議有一個管道,讓一般民眾提一些意見。廣
+ *data.gov.tw 可以算是目前的管道義的開放資料
*政府網站是否應該開放源碼?
*是否可接受民眾 pull request?
(73 行未修改)
*各單位是否建立單位內所有資料之列表,並評估不可釋出之資料後,提出資料開放之進程?回饋處理之效率及完成率
- 主動提升開放資料之建議做法
+ 主動提升開放資料之建議做品質法
*定期資料黑客松
*程式
- *由政府單位列出可提供之資料列表,於黑客松時應民眾需求提供,藉以了解自動審查
- *紙本資料全面電子化
+ *由政府單位列出可提供之資料列表,於黑客松時應民眾需求提供,藉以了解民間需求並獲取回饋以了解開放之資料品質
+ *審查
+ *紙本
+ *建立基本規則例如格式驗證, 編碼分析、縣市鄉鎮名稱比對等等先做一遍評量,可節省大量人工資料全面電子化
*
+
+
+ *透過民間力
|
||
| 2014-05-19 05:41 – 05:44 | r3716 – r3772 | |
顯示 diff(178 行未修改)
*也可為中文網址: http://data.gov.tw/內政/人口/台北市/大安區/2013/男性/25-30/資料即時之即
*資料若能隨時保持在最新也是大大加分。
- *例放資料品質的適當指標 (其他評分方式)
- *資料開放規劃及進程
- *民間回饋處理之效率及完成率
+ *例放品質的適當指的方式)
+ *資開放規劃及進程
+ *民間
+ *各單位是否建立單位內所有資料之列表,並評估不可釋出之資料後,提出資料開放之進程?回饋處理之效率及完成率
主動提升開放資料之建議做法
*定期資料黑客松
- *程式自動審查
+ *程式
+ *由政府單位列出可提供之資料列表,於黑客松時應民眾需求提供,藉以了解自動審查
*紙本資料全面電子化
*
|
||
| 2014-05-19 05:41 | r3715 | |
顯示 diff(189 行未修改)
|
||
| 2014-05-19 04:44 – 05:41 | r2821 – r3714 | |
顯示 diff(138 行未修改)
開放之資料必須具備的條件 (必要條件)
所有的必要條件都應該達成。若未能達到所有必要條件,則不及格。
- *資料格式開放
+ *資料開放率需夠高
+ *「不夠」開放的資料等於沒有開放
+ *使用正確且開放的格式
+ *(開放) 資料使用之格式應普及,並不需使用收費軟體開啓。例如,不應使用 doc, xls 等格式。
+ *(開放) 使用的格式應有格式之說明,讓任何人都能夠自行撰寫讀取程式。
+ *(正確) 應提供各類型資料之建議格式列表。例如,表列或統計資料應使用 csv ,不應使用 pdf。
*提供使用授權
+ *一般情況下,資料不應限制使用範圍及用途
+ *無論範圍受限與否,資料必須附帶其可用範圍的清楚說明
*提供資料說明
- *提供歷史資料
- *提供版本資料
- *足夠的資料細緻度
- *資料開放率需夠高
-
- 對開放資料品質有幫助的條件 (充份條件)
+ *應提供資料來源、計算公式、誤差範圍及其他與資料意涵之說明,避免資料遭誤用。
+ *例如,人口普查之方式,死亡率之計算法等等,給定經緯度之誤差範圍等等。對開放資料品質有幫助的條件 (充份條件)
若能達成充分條件,則為良好的開放資料。
- *資料規範統一
+ *足夠提供版本資訊
+ *明確記錄資料修訂的內容及時間。例如 2010 年台北縣更名為新北市,或村里改名、合併等資料。
+ *資料更改之記錄應視為另一種開放資料,並遵循所有開放資料應有之規範。
+ *提供歷史資料
+ *針對不同時間點提供不同版本之資料,例如給定一個時間點,取得當時隻全國村里界圖。
+ *過去曾釋出的資料在未來也應該能夠取得 (例如,YouBike 的資料並無留存,無法取得過往資料)
+ *資料統一
+ *政府應針對各類型的資料給與表現的標準。
+ *例如,各部會間提到台北市時,「臺北市」「台北市」「台北」都有人用,不統一造成混亂。
+ *又例如電話號碼 02-1234-56787、12345678、(02)12345678也都有人用,處理上有困難。
+ *常見的資料統一方針如下,僅為舉例
+ *統一使用 utf-8 編碼
+ *統一使用 markdown 或 html 排版
+ *統一使用代碼表示各鄉鎮,例如 ISO 3166-2:TW 中使用 TW-CYI 代表嘉義縣
+ *避免使用全形空白
+ *的資料細緻度
+ *例如,提供各鄉鎮而非各縣市的統計資料。
+ *又例如,提供經緯度而非概略地址(例如,中正路口檳榔攤斜對面之類)
*示範性資料展示平台
- *統一的 API 介面
- *提供資料之即時性
-
- 評鑑開放資料品質的適當指標 (其他評分方式)
+ *
+ *除了提供資料以外,也提供瀏覽之介面
+ *例如提供 shp 檔之餘,也可先在線上地圖預覽 shp 之內容統一的 API 介面
+ *
+ *例如由 data.gov.tw 統一使用 REST 規範提供資料。比方說,2013年台北市大安區男性 25~30歲人口數據可由下列網址提供:
+ *http://data.gov.tw/moi/population/taipei/daan/2提13/man/25-30/
+ *也可為中文網址: http://data.gov.tw/內政/人口/台北市/大安區/2013/男性/25-30/資料即時之即
+ *資料若能隨時保持在最新也是大大加分。
+ *例放資料品質的適當指標 (其他評分方式)
*資料開放規劃及進程
*民間回饋處理之效率及完成率
- 開放資料推動
+ 主動提升開放資料之建議做法
+ *定期資料黑客松
+ *程式自動審查
+ *紙本資料全面電子化
+ *
|
||
| 2014-05-19 04:44 | r2820 | |
顯示 diff(160 行未修改)
|
||
| 2014-05-19 04:44 – 04:44 | r2818 – r2819 | |
顯示 diff(157 行未修改)
*民間回饋處理之效率及完成率
- 主管機關
+ 開放資料推動
|
||
| 2014-05-19 04:44 | r2817 | |
顯示 diff(160 行未修改)
|
||
| 2014-05-19 04:07 – 04:44 | r2350 – r2816 | |
顯示 diff(127 行未修改)
*我覺得 Schee 那邊針對城市所做的調查感覺蠻不錯的:http://tw-city.census.okfn.org/
+
+ *意見匯整
+ 下方開始將上方的討論總結
+
+ *g0v 社群建議針對政府開放資料品質檢驗應注意之要點
+
+ 導言
+ 為促進民間創意發想,開放資料之原則應以負向表列為主 -- 除了表列出不應開放資料之外,所有的資料均應遵循適當原則公開給大眾使用。負向表列之建立則除非涉及法律或國安問題,應以儘量開放為原則。
+
+ 開放之資料必須具備的條件 (必要條件)
+ 所有的必要條件都應該達成。若未能達到所有必要條件,則不及格。
+ *資料格式開放
+ *提供使用授權
+ *提供資料說明
+ *提供歷史資料
+ *提供版本資料
+ *足夠的資料細緻度
+ *資料開放率需夠高
+
+ 對開放資料品質有幫助的條件 (充份條件)
+ 若能達成充分條件,則為良好的開放資料。
+ *資料規範統一
+ *示範性資料展示平台
+ *統一的 API 介面
+ *提供資料之即時性
+
+ 評鑑開放資料品質的適當指標 (其他評分方式)
+ *資料開放規劃及進程
+ *民間回饋處理之效率及完成率
+
+ 主管機關
|
||
| 2014-05-16 07:21 | r2349 | |
顯示 diff(109 行未修改)
*是否可接受民眾 pull request?
*若有的話,不涉及軍事機密之演算法是否可開放?
-
*科技部考不考慮利用、推廣並積極參與開源社群?
(16 行未修改)
|
||
| 2014-05-16 02:25 – 02:26 | r2344 – r2348 | |
顯示 diff(46 行未修改)
相似的資料應該統一建立在一份資料集中。比方說,生物多樣性資料。
- *自動化,盡量以已經建置資料庫系統的資料為基礎,定時、自動轉出資料,減少人工介入造成的錯誤與延遲
+ *自動化,盡量以已經置料庫系統的資料為基礎,定時、動轉出資料,減少人工介入造成的錯誤與延遲
*應該有一個統一的資料倉儲,在資料入倉前能夠設計一些自動檢查措施,提高資料的品質
*即時性
(28 行未修改)
- *除了上述兩項,可以用來評量的標準
+ 了上述兩項,可以用來評量的標準
*各單位資料開放量
*各單位資料開放進程
(46 行未修改)
|
||
| 2014-05-15 07:41 – 08:14 | r1658 – r2343 | |
顯示 diff(112 行未修改)
*科技部考不考慮利用、推廣並積極參與開源社群?
+
+ 開放資料五顆星的原則應用於資料品質的議題
+ *TimBL的開放資料五顆星所著重的點在於資料的開放性,因此第一顆星的開放資料就要是以開放授權釋出,若這資料還是結構化資料(非圖片,機器難以處理的),那滿足二顆星,如果進一步是非專屬格式,如CSV,則滿足三顆星,若資料可以開放到,資料集中每一筆資料本身在網路中都有一個URI來指涉,就滿足了第四顆星的開放資料,一般做法就是以RDF的格式,因為有了URI,所以資料集中的資料可以透過語意相互連結,這就是五顆星等級開放資料,也就是常說的Linked Open Data。
+ *政府資料要做到五顆星等級的資料在技術成本上很高,目前歐美各國也僅只有少數國家有,多數國家多是三顆星等級的資料,若有需求,再依照資料特性與系統服務的目的來轉換資料為RDF格式,並設計ontology(知識本體),扮演的角色很像資料庫的schema,促使資料能夠相互連結。
+ *若單就這開放資料五顆星的等級,個人覺得無法解決,目前開放資料品質的問題。拾人牙慧,英國ODI為開放資料證書(Open Data Certificates),設計出幾個資料品質評估面向,或許是可以參考的:
+ *法律需求(Legal Requirements):權利(Rights)、授權(Licensing)、隱私(Privacy)
+ *技術資訊(Technical Requirements):資料所在地(Locations)、格式(Formats)、信任(Trust)
+ *實用資訊(Practical Requirements):可檢索性(Findability)、 資料的準確性(Accuracy)、 品質(Quality)、保證(Guarantees)
+ *社會資訊(Social Requirements):文件檔案(Documentation)、支持(Support)、服務(Service)
其他意見
*(請補充)
(4 行未修改)
|
||
| 2014-05-12 09:39 – 09:42 | r1616 – r1657 | |
顯示 diff(5 行未修改)
由於資料品質定義廣,從資料量、更新頻率、正確性、詳細度、精確度、修改記錄到大家常談論的格式等都屬於品質的一環,希望能夠透過社群討論出一個完整且有效的方式,來提升政府開放資料的整體素質。
+
+ *5/2 會議記錄
+ *會議前討論:政府開放資料政策 Review
*討論
(109 行未修改)
|
||
| 2014-05-09 02:24 – 02:24 | r1597 – r1615 | |
顯示 diff(113 行未修改)
*(請補充)
小弟覺得目前大部分政府網站,其對象都是人。政府這邊還沒有建立專門針對程式應用,寫API管道的概念,是目前最大的問題。
+
+
+ *我覺得 Schee 那邊針對城市所做的調查感覺蠻不錯的:http://tw-city.census.okfn.org/
|
||
| 2014-05-08 10:35 – 10:41 | r1544 – r1596 | |
顯示 diff(32 行未修改)
*常用的資料類型要規範其形式。例如
*電話: 規定使用
- 2-23227787(市話) 、 886-223227787(國際) 、 *912312312(其他) 格式
- *地址
+ (2-)3227-787((話)) 8+86-22-3227-787((際))、 9123-123-12((他))式
+
+ *依照之前念到的改寫範例,以括號包覆選擇性輸入的區碼,國碼前面要有加號,以 - 為間隔(後者僅為易於觀看的理由)。*地址
*上面這個可follow VCard 規範? 然後地址也許順便也可以給一下經緯度
*排版文字: 使用 html 排版或是 white-space preserved 形式的排版?
(76 行未修改)
|
||
| 2014-05-08 08:52 – 08:54 | r1479 – r1543 | |
顯示 diff(12 行未修改)
*釋出格式應為開放格式
*可建立常見/推薦格式列表,比方說 csv, json, shp, topojson, px, png, etc...
- *程式可讀性
+ *小小分類一下:
+ *表格資料:建議使用 csv
+ *圖片資料:建議使用 png
+ *文件資料:建議使用 json
+ *....
+ **程式可讀性
*提供恰當授權
*可建立常用/推薦授權列表
(92 行未修改)
|
||
| 2014-05-08 07:56 – 07:59 | r1362 – r1478 | |
顯示 diff(52 行未修改)
*API
*例如,若有一天郵局開放地址中翻英的算法與資料,仍然可提供展示平台跟轉換 API。
- *API 架構與規範也需要訂好。可參考 google api , google maps, cse, plus, youtube 等等 api 的機制其實是統合的。東一份西一份什麼的,最討厭了。不同單位部會間應統一資料系統,例如
+ *API 架構與規範也需要訂好。可參考 google api , google maps, cse, plus, youtube 等等 api 的機制其實是統合的。東一份西一份什麼的,最討厭了。
+ *API盡量遵循標準format, 例如HATEOAS, SWAGGER 另外並提供api 相關的document
+ *可以的話也提供i18n API,方便開發i18n的相關應用不同單位部會間應統一資料系統,例如
*若牽涉數值表格,則都用 CSV
*人口數統計一律建立各年齡層統計表
(50 行未修改)
|
||
| 2014-05-08 05:12 – 05:15 | r1304 – r1361 | |
顯示 diff(21 行未修改)
*各種實體應有獨一無二的 id 可指涉 (像是縣市代碼)
*另外,即使是用名稱,也應用同個名稱指涉同個實體。臺北、台北這種分身問題應該要避免。
+ *目前organization目前有一份orgcode, 但目前沒有所有實體單位的清單
*資料要有妥善的說明,例如資料來源,計算方式,誤差值,數字單位等等。
*可降低資料誤用率
(3 行未修改)
2-23227787(市話) 、 886-223227787(國際) 、 *912312312(其他) 格式
*地址
+ *上面這個可follow VCard 規範? 然後地址也許順便也可以給一下經緯度
*排版文字: 使用 html 排版或是 white-space preserved 形式的排版?
*統一用markdown會不會比較好處理?提供統計數字時應同時提供原始資料備檢驗
(73 行未修改)
|
||
| 2014-05-08 03:13 – 03:31 | r1193 – r1303 | |
顯示 diff(17 行未修改)
*若需收費,需有適當理由,否則依規費法,收零元即可
*應建立收費準則,包含費用如何評估等等
+ *收費管道建議統一,節省各個部門自己找收費管道的時間,也讓整個系統更加單純。
*編碼應使用 utf-8,而且不應該再看到用圖片代替的文字了
*各種實體應有獨一無二的 id 可指涉 (像是縣市代碼)
(6 行未修改)
2-23227787(市話) 、 886-223227787(國際) 、 *912312312(其他) 格式
*地址
- *排版文字: 使用 html 排版或是 white-space preserved 形式的排版?提供統計數字時應同時提供原始資料備檢驗
+ *排版文字: 使用 html 排版或是 white-space preserved 形式的排版?
+ *統一用markdown會不會比較好處理?提供統計數字時應同時提供原始資料備檢驗
*歷史資料均應留存
* (Youbike 歷史資料現無記錄)試算表表格排版資訊移除後應該也要可讀
(5 行未修改)
*即時性
*從政府取得資料,到上傳至民間可取得管道上,時間應該不超過一天。
- *地震資訊、天氣資訊等應即時傳遞。如果有會更好的東西
+ *地震資訊、天氣資訊等應即時傳遞。
+ *特殊狀況
+ *大型特殊狀況,例如天災等,應即時建立API系統,讓民間網站可以快速建立。如果有會更好的東西
*使用 REST URL Pattern
*
(42 行未修改)
+ *是否應該有回饋資料錯誤的管道?
*紙本資料全面電子化計劃
- *有鑒於政治獻金、建築執照等資訊都是紙本掃描,這類形態的資料是否可以專案處理?全國性的清查此類資料,建立資料轉換小組,利用網站透過群眾外包或是雇員將資料建檔。廣義的開放資料
+ *有鑒於政治獻金、建築執照等資訊都是紙本掃描,這類形態的資料是否可以專案處理?全國性的清查此類資料,建立資料轉換小組,利用網站透過群眾外包或是雇員將資料建檔。
+ *讓一般民眾傳達意見的管道
+ *除了駭客之外,建議有一個管道,讓一般民眾提一些意見。廣義的開放資料
*政府網站是否應該開放源碼?
*是否可接受民眾 pull request?
(5 行未修改)
其他意見
*(請補充)
- *小弟覺得討論的一個重點是把人看得
+ 小弟覺得目前大部分政府網站,其對象都是人。政府這邊還沒有建立專門針對程式應用,寫API管道的概念,是目前最大的問題。
|
||
| 2014-05-08 03:13 | r1192 | |
顯示 diff(98 行未修改)
|
||
| 2014-05-08 03:08 – 03:13 | r1173 – r1191 | |
顯示 diff(34 行未修改)
相似的資料應該統一建立在一份資料集中。比方說,生物多樣性資料。
*自動化,盡量以已經建置資料庫系統的資料為基礎,定時、自動轉出資料,減少人工介入造成的錯誤與延遲
- *應該有一個統一的資料倉儲,在資料入倉前能夠設計一些自動檢查措施,提高資料的品質如果有會更好的東西
+ *應該有一個統一的資料倉儲,在資料入倉前能夠設計一些自動檢查措施,提高資料的品質
+ *即時性
+ *從政府取得資料,到上傳至民間可取得管道上,時間應該不超過一天。
+ *地震資訊、天氣資訊等應即時傳遞。如果有會更好的東西
*使用 REST URL Pattern
*
(53 行未修改)
其他意見
*(請補充)
+ *小弟覺得討論的一個重點是把人看得
|
||
| 2014-05-08 01:36 – 01:37 | r1159 – r1172 | |
顯示 diff(29 行未修改)
*排版文字: 使用 html 排版或是 white-space preserved 形式的排版?提供統計數字時應同時提供原始資料備檢驗
*歷史資料均應留存
- *試算表表格排版資訊移除後應該也要可讀
- *
+ * (Youbike 歷史資料現無記錄)試算表表格排版資訊移除後應該也要可讀
+ * (不要使用合併儲存格)
相似的資料應該統一建立在一份資料集中。比方說,生物多樣性資料。
(59 行未修改)
|
||
| 2014-05-07 22:40 – 22:41 | r1151 – r1158 | |
顯示 diff(69 行未修改)
*理論上夠好的資料應該很容易就可以轉換到相容的格式,例如 csv 轉成 xls 。這是否可列為指標之一?
+ *結構化資料是否有採用相關國際標準(是否有相關標準、採用部分為何、不採用原因為何)
法面上,讓資料變得更完善的機制該怎麼實作?
*定期的資料黑客松
(20 行未修改)
|
||
| 2014-05-07 16:57 – 17:01 | r1026 – r1150 | |
顯示 diff(11 行未修改)
政府開放資料應該要注意的地方
*釋出格式應為開放格式
- *可建立常見/推薦格式列表,比方說 csv, json, shp, px, etc...
+ *可建立常見/推薦格式列表,比方說 csv, json, shp, topojson, px, png, etc...
*程式可讀性
*提供恰當授權
(25 行未修改)
*GDP:可顯示線圖
*城市 3D模型: WebGL 預覽
- *API,以方便
- *不同單位部會間應統一資料系統,例如
+ *API
+ *例如,若有一天郵局開放地址中翻英的算法與資料,仍然可提供展示平台跟轉換 API。
+ *API 架構與規範也需要訂好。可參考 google api , google maps, cse, plus, youtube 等等 api 的機制其實是統合的。東一份西一份什麼的,最討厭了。不同單位部會間應統一資料系統,例如
*若牽涉數值表格,則都用 CSV
*人口數統計一律建立各年齡層統計表
(10 行未修改)
*程式可處理之勘誤表 (如 patch file or 資料建入版本管理系統)
- 除了上述兩項,可以用來評量的標準
+
+ *除了上述兩項,可以用來評量的標準
*各單位資料開放量
*各單位資料開放進程
(3 行未修改)
*民間的評鑑
- 做法面上,讓資料變得更完善的機制該怎麼實作?
+
+ *理論上夠好的資料應該很容易就可以轉換到相容的格式,例如 csv 轉成 xls 。這是否可列為指標之一?
+ 法面上,讓資料變得更完善的機制該怎麼實作?
*定期的資料黑客松
*獎金鼓勵參與?或是利用更現代的方式例如成就系統之類的..
(19 行未修改)
|
||
| 2014-05-07 16:56 | r1025 | |
顯示 diff(34 行未修改)
相似的資料應該統一建立在一份資料集中。比方說,生物多樣性資料。
*自動化,盡量以已經建置資料庫系統的資料為基礎,定時、自動轉出資料,減少人工介入造成的錯誤與延遲
- *應該有一個統一的資料倉儲,在資料入倉前能夠設計一些自動檢查措施如果有會更好的東西
+ *應該有一個統一的資料倉儲,在資料入倉前能夠設計一些自動檢查措施,提高資料的品質如果有會更好的東西
*使用 REST URL Pattern
*
(50 行未修改)
|
||
| 2014-05-07 16:56 – 16:56 | r1012 – r1024 | |
顯示 diff(40 行未修改)
*地理相關,如地標:依經緯度可在地圖上預覽
*GDP:可顯示線圖
- *城市 3D模型: WebGL 預覽不同單位部會間應統一資料系統,例如
+ *城市 3D模型: WebGL 預覽
+ *API,以方便
+ *不同單位部會間應統一資料系統,例如
*若牽涉數值表格,則都用 CSV
*人口數統計一律建立各年齡層統計表
(42 行未修改)
|
||
| 2014-05-07 16:55 – 16:56 | r1010 – r1011 | |
顯示 diff(33 行未修改)
相似的資料應該統一建立在一份資料集中。比方說,生物多樣性資料。
- *自動化,盡量以已經建置資料庫系統的資料為基礎,定時、自動轉出資料,減少人工介入造成的錯誤與延遲如果有會更好的東西
+ *自動化,盡量以已經建置資料庫系統的資料為基礎,定時、自動轉出資料,減少人工介入造成的錯誤與延遲
+ *應該有一個統一的資料倉儲,在資料入倉前能夠設計一些自動檢查措施如果有會更好的東西
*使用 REST URL Pattern
*
(48 行未修改)
|
||
| 2014-05-07 16:55 – 16:55 | r1008 – r1009 | |
顯示 diff(22 行未修改)
*資料要有妥善的說明,例如資料來源,計算方式,誤差值,數字單位等等。
*可降低資料誤用率
- *甚至資料建置的成本、人力等等都可以
+ *甚至資料建置的成本、人力等等都可以附帶?有需要嗎?
*常用的資料類型要規範其形式。例如
*電話: 規定使用
(59 行未修改)
|
||
| 2014-05-07 16:55 | r1007 | |
顯示 diff(33 行未修改)
相似的資料應該統一建立在一份資料集中。比方說,生物多樣性資料。
- *如果有會更好的東西
+ *自動化,盡量以已經建置資料庫系統的資料為基礎,定時、自動轉出資料,減少人工介入造成的錯誤與延遲如果有會更好的東西
*使用 REST URL Pattern
*
(48 行未修改)
|
||
| 2014-05-07 16:54 – 16:55 | r992 – r1006 | |
顯示 diff(19 行未修改)
*編碼應使用 utf-8,而且不應該再看到用圖片代替的文字了
*各種實體應有獨一無二的 id 可指涉 (像是縣市代碼)
- *另外,即使是用名稱,也應用同個名稱指涉同個實體。臺北、台北之類的問題應該要被統一成其中一者。
- *資料要有妥善的說明,例如計算方式,誤差值,數字單位等等。
+ *另外,即使是用名稱,也應用同個名稱指涉同個實體。臺北、台北這種分身問題應該要避免。
+ *資料要有妥善的說明,例如資料來源,計算方式,誤差值,數字單位等等。
*可降低資料誤用率
+ *甚至資料建置的成本、人力等等都可以
*常用的資料類型要規範其形式。例如
*電話: 規定使用
(59 行未修改)
|
||
| 2014-05-07 16:54 – 16:54 | r990 – r991 | |
顯示 diff(32 行未修改)
相似的資料應該統一建立在一份資料集中。比方說,生物多樣性資料。
- *ㄉㄨ如果有會更好的東西
+ *如果有會更好的東西
*使用 REST URL Pattern
*
(48 行未修改)
|
||
| 2014-05-07 16:54 – 16:54 | r988 – r989 | |
顯示 diff(19 行未修改)
*編碼應使用 utf-8,而且不應該再看到用圖片代替的文字了
*各種實體應有獨一無二的 id 可指涉 (像是縣市代碼)
- *另外,即使是用名稱,也應用同個名稱指涉實體。臺北、台北之類的問題應該要被統一成其中一者。
+ *另外,即使是用名稱,也應用同個名稱指涉同個實體。臺北、台北之類的問題應該要被統一成其中一者。
*資料要有妥善的說明,例如計算方式,誤差值,數字單位等等。
*可降低資料誤用率
(61 行未修改)
|
||
| 2014-05-07 16:54 | r987 | |
顯示 diff(32 行未修改)
相似的資料應該統一建立在一份資料集中。比方說,生物多樣性資料。
- *#ㄉㄨ如果有會更好的東西
+ *ㄉㄨ如果有會更好的東西
*使用 REST URL Pattern
*
(48 行未修改)
|
||
| 2014-05-07 16:54 – 16:54 | r985 – r986 | |
顯示 diff(19 行未修改)
*編碼應使用 utf-8,而且不應該再看到用圖片代替的文字了
*各種實體應有獨一無二的 id 可指涉 (像是縣市代碼)
- *另外,即使是用名稱,也應用同個名稱指涉一個實體。臺北、台北之類的問題應該要被統一成其中一者。
+ *另外,即使是用名稱,也應用同個名稱指涉實體。臺北、台北之類的問題應該要被統一成其中一者。
*資料要有妥善的說明,例如計算方式,誤差值,數字單位等等。
*可降低資料誤用率
(61 行未修改)
|
||
| 2014-05-07 16:54 – 16:54 | r983 – r984 | |
顯示 diff(32 行未修改)
相似的資料應該統一建立在一份資料集中。比方說,生物多樣性資料。
- *字ㄉㄨ如果有會更好的東西
+ *#ㄉㄨ如果有會更好的東西
*使用 REST URL Pattern
*
(48 行未修改)
|
||
| 2014-05-07 16:54 | r982 | |
顯示 diff(19 行未修改)
*編碼應使用 utf-8,而且不應該再看到用圖片代替的文字了
*各種實體應有獨一無二的 id 可指涉 (像是縣市代碼)
- *另外,即使是用名稱,也應用同一個名稱指涉一個實體。臺北、台北之類的問題應該要被統一成其中一者。
+ *另外,即使是用名稱,也應用同個名稱指涉一個實體。臺北、台北之類的問題應該要被統一成其中一者。
*資料要有妥善的說明,例如計算方式,誤差值,數字單位等等。
*可降低資料誤用率
(61 行未修改)
|
||
| 2014-05-07 16:54 – 16:54 | r980 – r981 | |
顯示 diff(85 行未修改)
|
||
| 2014-05-07 16:54 | r979 | |
顯示 diff(19 行未修改)
*編碼應使用 utf-8,而且不應該再看到用圖片代替的文字了
*各種實體應有獨一無二的 id 可指涉 (像是縣市代碼)
- *另外,即使是用名稱,也應該用同一個名稱指涉一個實體。臺北、台北之類的問題應該要被統一成其中一者。
+ *另外,即使是用名稱,也應用同一個名稱指涉一個實體。臺北、台北之類的問題應該要被統一成其中一者。
*資料要有妥善的說明,例如計算方式,誤差值,數字單位等等。
*可降低資料誤用率
(61 行未修改)
|
||
| 2014-05-07 16:54 | r978 | |
顯示 diff(32 行未修改)
相似的資料應該統一建立在一份資料集中。比方說,生物多樣性資料。
- *如果有會更好的東西
+ *字ㄉㄨ如果有會更好的東西
*使用 REST URL Pattern
*
(48 行未修改)
|
||
| 2014-05-07 16:54 – 16:54 | r976 – r977 | |
顯示 diff(19 行未修改)
*編碼應使用 utf-8,而且不應該再看到用圖片代替的文字了
*各種實體應有獨一無二的 id 可指涉 (像是縣市代碼)
- *另外,即使是用名稱應該用同一個名稱指涉一個實體。臺北、台北之類的問題應該要被統一成其中一者。
+ *另外,即使是用名稱,也應該用同一個名稱指涉一個實體。臺北、台北之類的問題應該要被統一成其中一者。
*資料要有妥善的說明,例如計算方式,誤差值,數字單位等等。
*可降低資料誤用率
(61 行未修改)
|
||
| 2014-05-07 16:54 | r975 | |
顯示 diff(31 行未修改)
*
- 相似的資料應該統一建立在一份資料集中。比方說,生物多樣性資料。如果有會更好的東西
+ 相似的資料應該統一建立在一份資料集中。比方說,生物多樣性資料。
+ *如果有會更好的東西
*使用 REST URL Pattern
*
(48 行未修改)
|
||
| 2014-05-07 16:23 – 16:54 | r526 – r974 | |
顯示 diff(11 行未修改)
政府開放資料應該要注意的地方
*釋出格式應為開放格式
+ *可建立常見/推薦格式列表,比方說 csv, json, shp, px, etc...
*程式可讀性
*提供恰當授權
+ *可建立常用/推薦授權列表
*若需收費,需有適當理由,否則依規費法,收零元即可
- *編碼:utf-8,不應該再看到圖片了
- *各種實體是否有獨一無二的 id 可指涉?(像是縣市代碼)
+ *應建立收費準則,包含費用如何評估等等
+ *編碼應使用 utf-8,而且不應該再看到用圖片代替的文字了
+ *各種實體應有獨一無二的 id 可指涉 (像是縣市代碼)
+ *另外,即使是用名稱應該用同一個名稱指涉一個實體。臺北、台北之類的問題應該要被統一成其中一者。
*資料要有妥善的說明,例如計算方式,誤差值,數字單位等等。
- *提供統計數字時應同時提供原始資料備檢驗
+ *可降低資料誤用率
+ *常用的資料類型要規範其形式。例如
+ *電話: 規定使用
+ 2-23227787(市話) 、 886-223227787(國際) 、 *912312312(其他) 格式
+ *地址
+ *排版文字: 使用 html 排版或是 white-space preserved 形式的排版?提供統計數字時應同時提供原始資料備檢驗
*歷史資料均應留存
*試算表表格排版資訊移除後應該也要可讀
+ *
- 如果有會更好的東西
+ 相似的資料應該統一建立在一份資料集中。比方說,生物多樣性資料。如果有會更好的東西
*使用 REST URL Pattern
- *不同單位部會間應統一資料系統,例如
+ *
+ *示範性資料展示平台,例如
+ *地理相關,如地標:依經緯度可在地圖上預覽
+ *GDP:可顯示線圖
+ *城市 3D模型: WebGL 預覽不同單位部會間應統一資料系統,例如
*若牽涉數值表格,則都用 CSV
*人口數統計一律建立各年齡層統計表
(18 行未修改)
*民間的評鑑
- 廣義的開放資料
+ 做法面上,讓資料變得更完善的機制該怎麼實作?
+ *定期的資料黑客松
+ *獎金鼓勵參與?或是利用更現代的方式例如成就系統之類的..
+ *專門的評鑑機構
+ *資料上線後,可送至機構審查,不曉得是否為好做法?
+ *程式自動審查
+ *開放資料同時提供 meta data,由程式檢查欄位是否齊全
+ *編碼、表格的資料形態,
+ *資料正確性 (比方說, 明明是縣市名稱,卻跑出鄉鎮名,或是名字打錯)
+
+
+ *紙本資料全面電子化計劃
+ *有鑒於政治獻金、建築執照等資訊都是紙本掃描,這類形態的資料是否可以專案處理?全國性的清查此類資料,建立資料轉換小組,利用網站透過群眾外包或是雇員將資料建檔。廣義的開放資料
*政府網站是否應該開放源碼?
*是否可接受民眾 pull request?
*若有的話,不涉及軍事機密之演算法是否可開放?
+
+
+ *科技部考不考慮利用、推廣並積極參與開源社群?
+
+ 其他意見
+ *(請補充)
|
||
| 2014-05-07 16:23 – 16:23 | r507 – r525 | |
顯示 diff(32 行未修改)
*交通事故可提供經緯度
*無資料但有經費的前提下,可將提升資料細緻度規劃至單位未來的施政計劃中
+ *有類似 RSS 機制可以知道資料更新
*資料錯誤回報平台
*透過 id 指涉錯誤資料以利回報
(15 行未修改)
|
||
| 2014-05-07 16:22 – 16:22 | r496 – r506 | |
顯示 diff(48 行未修改)
*政府網站是否應該開放源碼?
*是否可接受民眾 pull request?
- *
+ *若有的話,不涉及軍事機密之演算法是否可開放?
|
||
| 2014-05-07 16:22 | r495 | |
顯示 diff(51 行未修改)
|
||
| 2014-05-07 16:17 – 16:22 | r398 – r494 | |
顯示 diff(32 行未修改)
*交通事故可提供經緯度
*無資料但有經費的前提下,可將提升資料細緻度規劃至單位未來的施政計劃中
+ *資料錯誤回報平台
+ *透過 id 指涉錯誤資料以利回報
+ *資料修正進度查詢
+ *程式可處理之勘誤表 (如 patch file or 資料建入版本管理系統)
- 評量的標準
+ 除了上述兩項,可以用來評量的標準
+ *各單位資料開放量
+ *各單位資料開放進程
+ *各單位根據民間回饋的資料修正率
+ *開放資料五顆星達成率
+ *資料開放格式是否滿足上級單位之要求
+ *民間的評鑑
+
+ 廣義的開放資料
+ *政府網站是否應該開放源碼?
+ *是否可接受民眾 pull request?
+ *
|
||
| 2014-05-07 16:17 | r397 | |
顯示 diff(36 行未修改)
|
||
| 2014-05-07 16:10 – 16:17 | r248 – r396 | |
顯示 diff(11 行未修改)
政府開放資料應該要注意的地方
*釋出格式應為開放格式
+ *程式可讀性
+ *提供恰當授權
+ *若需收費,需有適當理由,否則依規費法,收零元即可
*編碼:utf-8,不應該再看到圖片了
*各種實體是否有獨一無二的 id 可指涉?(像是縣市代碼)
(1 行未修改)
*提供統計數字時應同時提供原始資料備檢驗
*歷史資料均應留存
+ *試算表表格排版資訊移除後應該也要可讀
如果有會更好的東西
*使用 REST URL Pattern
+ *不同單位部會間應統一資料系統,例如
+ *若牽涉數值表格,則都用 CSV
+ *人口數統計一律建立各年齡層統計表
+ *依此類推
+ *若各單位釋出同質性資料,應由上級單位規範格式
+ *有資料的前提下,資料單位越細越好,提供統計資料不如提供原始資料。例如
+ *各鄉鎮人口資訊可做至村里甚至鄰
+ *交通事故可提供經緯度
+ *無資料但有經費的前提下,可將提升資料細緻度規劃至單位未來的施政計劃中
+
+ 評量的標準
|
||
| 2014-05-07 16:10 | r247 | |
顯示 diff(21 行未修改)
|
||
| 2014-05-07 16:03 – 16:10 | r115 – r246 | |
顯示 diff(4 行未修改)
5/2 零時政府參與者 jimmyhuang, muyueh & tkirby 前往科技部參與開放資料座談,座談中提及五星開放資料與資料品質的問題,張善政部長談到請零時政府評估是否可能協助建立資料品質檢測的機制。
- 由於資料品質定義廣,從資料量、更新頻率、正確性、詳細度、精確度、修改記錄到大家常談論的格式等都屬於品質的一環,
+ 由於資料品質定義廣,從資料量、更新頻率、正確性、詳細度、精確度、修改記錄到大家常談論的格式等都屬於品質的一環,希望能夠透過社群討論出一個完整且有效的方式,來提升政府開放資料的整體素質。
+
+ *討論
+ (先隨便列些綱目,請自己加)
+
+ 政府開放資料應該要注意的地方
+ *釋出格式應為開放格式
+ *編碼:utf-8,不應該再看到圖片了
+ *各種實體是否有獨一無二的 id 可指涉?(像是縣市代碼)
+ *資料要有妥善的說明,例如計算方式,誤差值,數字單位等等。
+ *提供統計數字時應同時提供原始資料備檢驗
+ *歷史資料均應留存
+
+ 如果有會更好的東西
+ *使用 REST URL Pattern
|
||
| 2014-05-07 16:03 | r114 | |
顯示 diff(7 行未修改)
|
||
| 2014-05-07 16:01 – 16:03 | r76 – r113 | |
顯示 diff(4 行未修改)
5/2 零時政府參與者 jimmyhuang, muyueh & tkirby 前往科技部參與開放資料座談,座談中提及五星開放資料與資料品質的問題,張善政部長談到請零時政府評估是否可能協助建立資料品質檢測的機制。
- 由於資料
+ 由於資料品質定義廣,從資料量、更新頻率、正確性、詳細度、精確度、修改記錄到大家常談論的格式等都屬於品質的一環,
|
||
| 2014-05-07 16:01 | r75 | |
顯示 diff(7 行未修改)
|
||
| 2014-05-07 15:52 – 16:01 | r1 – r74 | |
顯示 diff- Untitled
+ 政府開放資料品質檢驗機制
- This pad text is synchronized as you type, so that everyone viewing this page sees the same text. This allows you to collaborate seamlessly on documents!
+ *緣起
+
+ 5/2 零時政府參與者 jimmyhuang, muyueh & tkirby 前往科技部參與開放資料座談,座談中提及五星開放資料與資料品質的問題,張善政部長談到請零時政府評估是否可能協助建立資料品質檢測的機制。
+
+ 由於資料
|
||
| 2014-05-07 15:52 | r0 | |
顯示 diff+ Untitled
+ This pad text is synchronized as you type, so that everyone viewing this page sees the same text. This allows you to collaborate seamlessly on documents!
|
||