資料轉成RDF就是4星級資料了嗎?

因產銷履歷農產品鏈結資料之計畫所需,在data.gov.tw上尋找食品業者登錄資料集,意外的發現這筆資料居然提供RDF格式,不但如此,衛福部食藥署還有一個LOD的網頁,集合了他們製作的RDF資料集。引起了我的好奇,去看看這些RDF的資料,若他們的資料與系統完備,我們的產銷履歷農產品RDF資料即可以和衛福部食藥署的RDF資料連結,但看完資料後覺得有些建議,提出來和大家分享。

<rdf:Description rdf:about="http://data.fda.gov.tw/lod/tfda/FoodCompanyRegistration_VIEW/DATA_SN/6833319">
   <rdf:type rdf:resource="http://data.fda.gov.tw/lod/schemas/tfda/FoodCompanyRegistration_VIEW"/>
   <tfda:公司或商業登記名稱>早安!美芝城仁愛店</tfda:公司或商業登記名稱>
   <tfda:食品業者登錄字號>E-200028714-00002-7</tfda:食品業者登錄字號>
   <tfda:登錄項目>販售場所</tfda:登錄項目>
   <tfda:公司統一編號/>
   <tfda:業者地址>高雄市新興區仁愛一街177號</tfda:業者地址>
</rdf:Description>

上述是食品業者登錄資料集中的一筆資料,沒有了URL,其它的格式的資料沒有什麼不一樣。URL所指涉的是一件事物,讓別人可以去連結這份資料,而在食品業者登錄資料集中,主體是「食品公司」,所以<http://data.fda.gov.tw/lod/tfda/FoodCompanyRegistration_VIEW/DATA_SN/6833319> 指的是一個「食品公司」,即是「早安!美芝城仁愛店」,可被連結的。「早安!美芝城仁愛店」是一個實例(instance),而「食品公司」則是類別(class),因此rdf:type中應該指的是「食品公司」,就是<http://data.fda.gov.tw/lod/schemas/tfda/FoodCompanyRegistration_VIEW>。

1. URL 設計不良

邏輯上,這個RDF 的表達沒有錯,但就URL的設計而言,實在很糟禚。為什麼不簡單清楚一些? 例如,類別的名稱簡單清楚,用FoodCompany取代FoodCompanyRegistration_VIEW,因此,<http://data.fda.gov.tw/ontology/FoodCompany>來指食品公司的類別(class),而<http://data.fda.gov.tw/ontology/FoodCompany/6833319>來指「早安!美芝城仁愛店」這家店。

其實URL的設計是有一些原則,其詳情可以參考W3C的文件 Cool URIs for the Semantic Web

2. RDF與知識本體應一致

再者,這份RDF中的標籤使用中文,但知識本體的宣告卻是英文,這樣的做法機器是沒辦法知道RDF內用中文宣告的屬性,在知識本體中是對到那一個英文。或是說URL根本就不一樣,怎麼有可能對在一起!

3.提供SPARQL查詢

RDF資料通常會利用三元組儲存庫(triple stores)來管理、儲存和查詢資料,這些三元組儲存庫通常也可以透過網路提供SPARQL的查詢服務,因此常稱為SPARQL endpoints,這些工具的技術都己經成熟,而且也有自由軟體可以利用,同時因開放碼源,也可以客製化成自己需求的服務,如果使用者還是把資料下載再使用,那用URL去指稱事物的功能,在網路上就無法發揮更好的效用。

4.缺乏利用既有語彙

為了資料容易整合,在建立資料知識本體時,多考慮使用標準或既有的語彙為主,以增加資料的可再使用性。食藥署的這批RDF資料,無論在類別或屬性都有標準或既有的語彙,是可以考慮多使用這些語彙。

在火車誤點背後的資訊化落後問題

開放資料的問題常常是從自身的日常生活開始。二週前,從花蓮回到台北時,搭了一班假日加班車自強號253次,從花蓮出發,中途就只停松山,而終點站是台北,整個車程只有三站,但當日(12/18)的車次在抵達松山時已經是誤點3分鐘,遲到時間不多,但在深夜時段、沒有乘客上下車的情形下,還會誤點,這就很有問題。

台鐵其實很少準時

很好奇地在網路上著手查詢一下台鐵誤點資料,發現交通部統計查詢網中,可以找到歷年來各種火車類別的到站準點率,但有趣的是,其中有些資料,例如客運量,已經在政府資料開放平台上發佈,但準點率的統計卻沒有,為什麼呢?

透過各種列車的每月平均到站準點率之統計資料,把過去10年的資料攤開來看,結果很有趣,慢車比快車準時,普通車才有可能達到一整個月都準時,整體而言,準點到站率表現最好,其次是區間車,莒光號與自強號半斤八兩,這樣的結果難道沒有人覺得很不合理嗎?!

是! 這個問題確是在2015年10月時,就有立法委員提出來要求台鐵改善,要求成立專責小組,當時的交通部長還要求台鐵在半年月內改善,然而,這件事就在總統大選與政府輪替後,又石沉大海,大家好像又習慣了台鐵的誤點,對於經常性的誤點只有無奈以對,或者是自嘲地挺過一次次等嘸車的無奈。

台鐵誤點讓使乘客等車等了"一年" (截圖於爆社公社臉書社團)

誤點原因

自由新聞報導台鐵早在2014年委託財團法人成大研究發展基金會,分析比對2014年1~6月間列車的ATP行車紀錄、班表紀錄及售票紀錄、和誤點紀錄,以調查造成誤點原因,其結果歸納出幾個,

  1. 發現旅客過多或個別旅客因素、
  2. 通過施工處減速、
  3. 列車會車避讓他車、
  4. 被先前列車延誤、
  5. 電車線故障。

這個分析的結果引發討論,並有人認為旅客過多,是台鐵本來應該利用路線設計和引導去解決的問題,不應該把責任推給旅客。

資料是提昇服務的關鍵

火車誤點一定會有一些不可抗力的因素,例如,上述所提到的因施工需要減速,或是突發狀況,例如設施故障或交通意外,對於一個乘客而言,事先了解發生什麼事而誤點,可避免這搭乘這些路線的列車,在車上的旅客了解誤點的原因,可以安心的搭乘。從台鐵委託成大的研究可以知道,台鐵都有這些資料,那為什麼不善用這些資料提供更好的服務呢? 即使台鐵本身沒有能力開發更好的服務系統(訂票系統令人失望呀!),只要把這些資料以結構化且開放授權的方式釋出,也一定有高人可以利用這些資料來開發應用程式。

相對於台鐵,荷蘭國鐵算準時,但也常誤點,對於施工所造成的誤點,不但會在手機APP上提醒,也會在火車時刻查詢系統中加入預估延遲的時間,在搭車前可以避免搭乘會誤點的列車,或是有延遲的心理準備

透明化的荷鐵施工資訊

 

整合施工資訊於火車時刻查詢系統

而荷鐵不但自已有APP和應用程式服務旅客,進一步地,荷鐵把提供服務的資料一併以API方式釋出,被視為開放資料,但授權方式不是很清楚,限制是每日不能超過5萬次查詢(request)。也因為有這樣的開放的API,其資料可被使用的方式就變得多樣,例如,NS API可以查詢到每一班火車的實際位置,因此有人利用這個資料結合OSM開發出即時的火車動態圖

利用荷鐵Open API 整合OSM 製作即時動態火車地圖

開放資料是台鐵轉變的契機!?

事實上台鐵委託成大的研究中,只用了6個月的資料,台鐵在交通部的統計資料至少有20年,6個月可以做的分析,20年為什麼不能做? 那若是利用完整的資料的分析,其結果又是如何? 對於一個好奇的人,會更想利用這些資料去了造成台鐵火車誤點的原因,為什麼慢車比快車準時? 為什麼看似沒什麼事發生、也沒停站,火車還是誤點? 數字能說話,但資料那裡呢? 提供成大分析的資料為什麼不能一併開放呢?

開放資料是一種文化,台鐵情況讓我想到台電在去年轉變的案例,在核能與缺電的議題下,對於缺電的原因,大家總覺得台電說的不清不楚,因此引來「開放台電」行動,想要從資料中討論缺電的原因。無論這個行動的過程中所發生的爭議是如何,為台電帶來的最大獲益應該是面對資料開放的態度和如何利用資料解決問題,同樣的,台鐵是否也能從開放資料開始來解決問題呢? 火車誤點在台鐵是司空見慣之事,但背後所隱含的恐怕是一個國營事業單位的資訊化落後,而無法發現問題、解決問題的窠臼。