開放資料「平台」的快速成長

開放資料平台真的再迅速成長,繼上星期立法院開放資料,剛剛又看到:商工行政資料開放平臺。台灣的開放資料平台,每兩個星期就有一個新平台。

我最近一直好奇的問題:

就是到底是越多資料平台越好,還是越少越好?

我的意思是,現在從事 SheetHub.com 的一個核心想法,就是希望可以只有一個開放平台:所有的資料都倒進來,然後只有一個統一的 API 接口。因為照理來講,越多開放平台是越糟的。

但在爬資料,遇到的問題是,資料本身的品質真的很可怕。有幾種情勢的可怕:

API 太有個性

這裡指的是不同的開放資料 API,往往會要求開方者有不同的開發方式,這是為什麼每一個開放平台都需要重新寫一個爬蟲,並且可以寫一篇文章。 舉例,像是一般的 JSON 回覆是 [{資料}, {資料}, {資料}],但新竹縣 的 API 卻是 {Table: [{資料}, {資料}, {資料}]}。在這一個例子裡,這當然是合法的 JSON,但這一種適用方式,就跟其他使用方式不同,使用資料的時候就會很痛苦。而當這些資料都集中在同一個資料平台的時候,會比起要改善多個資料平台來得容易許多。所以以這一點來說,越少平台是越好的。以 SheetHub 來說,我們的 JSON 格式的確有一點個性:除了資料,我們把 colums header 獨立送,以節省空間,並還送了一些其他關於此資料及的 overhead。但我們也開放了包含 csv、xls 人跟機器都很好讀的資料格式。

資料格式太混亂的可怕

資料格式,像是:

  • 試算表相關:xls, xlsx, csv, tsv, xml, json, doc, docx, pdf, html;其中 xls 相關的還需要兼顧一個試算表裡面有多個 sheet。其中 doc, docx, pdf, html 應該不屬於這一個類別,但實際上是很多表格是鎖在這樣的檔案被釋放。
  • 地理相關:shp, geojson, topojson, kmz, kml
  • 經過 zip, rar 的壓縮檔
  • 編碼格式,這一種東西,會讓你再打開檔案的時候出現亂碼:utf-8、Big5、或甚至 utf-16。

所幸上述資料格式的混亂大都可以透過程式解決,所以比方說 Ronny 解決編碼的方法,是用每一種編碼都先試一次,看哪一個不會有亂碼。這雖然會讓程式變得小複雜,還是有解。在這裡,有統一平台的好處,是把不同的格式匯入,然後一次再提供各種格式給不同的使用者。

資料品質太低

比方:

  • jpg, png, 以圖片儲存的 pdf。
  • 與機器不相容的儲存方式,比方使用 excel 合併儲存格,對機器要判斷起來挺麻煩的。另外像是在 csv 檔案包著一層 html,或著是 html 中用錯誤的方式產生表格。或著是更常見的 csv、json 的格式錯誤(逗號沒有 escape )。
  • 完全壞掉的連結,像是這一個例子:開放出來的圖片連結居然是(公務員?)本機的 C 槽硬碟。

這些問題非常瑣碎,需要大量的人工處理。回頭跟「越多開放平台會不會越好」有一點關係。我的觀察,是諸如食藥署,就把裡面的資料清理的相對高品質。這是整一個論述裡面,我會稍微猶豫的地方:以這一個例子,架設平台跟較高資料品質有關係?假如有關係的話,是有因果的嗎:因為很在乎資料所以才自己架設平台?還是自己架設平台所以很關心?

我覺得這一個問題隱含的,是每一個資料其實都需要一定的人工去讓他變成結構性的資料,在資料五顆星架構下的 一顆星 -> 兩顆星

只要東西是兩顆星之後,問題都很好解決,像是現在資料只要匯入 SheetHub,機器就會自動解決兩顆星 -> 五顆星 的問題。

我自己對國發會的觀察,是歷經幾次會議,定位從「要一定標準才可以釋放」(三顆星標準?),到現在比較接近「有資料先放在說」。我覺得是正確的做法。因為國發會所處的位置,最必要的工作應該是要讓資料出現,從零顆星到一顆星。除了政府以外,再也沒有其他人可以做這一件事了。

比起開發 fancy 的資料應用,政府應該專注在資料的釋出、品質。我可以舉的例子,是現在金管會的開放資料,非得要給經緯度才會吐回資料。這真的非常困擾。為什麼不直接提供一個所有資料的經緯度,讓使用者自己開放應用。

現在國發會致力在開放新的資料,而每天都有 30 到 50 個新的資料集。我覺得是一個相當理想的狀況。

下一個問題,反而是多了許多的資料,而不夠多的人可以清理這些資料。

值得問的問題是:

可不可以透過「科技來解決」?或許沒有辦法完全解決,但任何有可能加速一顆星到兩顆星的過程?

我可以想到的是:

  • 開放政治獻金專案中,以系統降低數位化資料的門檻。
  • 或許現在很多資料會很骯髒,是因為使用者看不到。也就是說,這些人在交出去檔案的時候,其實沒有一個很好的機制。幾個 check 的機制包含檢查整個檔案的欄位數量是不是一致、parsing 的時候有沒有錯誤。像是我在清理檔案的時候,很常是在上傳到 SheetHub 之後才發現資料有錯。

假如資料的擁有者,不是只是把一個資料檔案交出去,而是親自上傳到一個地方,而可以馬上直接預覽,那可能檔案出錯的機率也會少很多。

TODO: 某一種資料 checker,可以立刻讓使用者有回饋,知道這不是不是好的(JSON, excel, csv)格式

  • 更強大的清理工具,這也是我們現在開發:refine.ls 的動機。主要的靈感來自於之前使用的 Google (Open) Refine,進而想要重新寫一個可以在瀏覽器使用,javascript 為主的工具。可以幫助大家更簡單的清理資料,並重複使用程式碼。

API

我們可以讓很多的資料匯入一個平台,再讓這一個平台產生使用者多種需要的格式(想像日期,我們需要把多種日期格式 78/01/01、2001/01/01 標準化,然後再依據使用者的需求提供多種版本)

統整

越多開放資料平台應該是不理想的狀況。資料越多越好,但平台數量應該越少越好。過程中,我們可能需要把多格式標準化,然後再提供多種使用者需要的形式。把兩顆星到五顆星到工作交給民間,讓政府專注在零顆星到一顆星的部份。一顆星到兩顆星的部份會需要很多的人力,透過更好的工具,應該可以讓數位化、清理、驗證的動作更簡單。