開放街圖(OSM)將成為谷歌地圖(Google Map)的最大爭競者嗎?

常有人問起,開放街圖(OpenStreetMap)能不能商業化? 或開放街圖能有什麼商機? 隨著上個月Telenav宣布他們的產品Scout捨棄了與TomTom的合作關係,而轉為使用開放街圖,這個問題似乎有一個強而有力的答案。事實上,不少網路媒體、甚至是紐約時報都認為TeleNav的做法將為適地性服務(Location-Based Service, LBS)和導航產業的市場帶來許多衝擊和轉變,但就一個圖客(Mappers)而言,開放街圖能被一家具規模的導航公司所使用,其實背後有更有意義。

TeleNav uses OSM

利用開放街圖為導航地圖這件事並不新鮮,開放街圖的維基上有一堆這些的服務,但能被一個在那斯達克(NASDAQ)上市的導航商所用,就別具意義,顯示出群眾外包(Crowdsourcing)的地圖己經被重視,且逐漸進入商業使用的階段。然而,群眾外包的地圖最大的疑慮是資料品質,像開放街圖在這種開放的系統,誰都可以來畫地圖,很難保證被畫上的地圖是正確的,但開放街圖並沒有太多的限制,每個帳戶是平等的,只要有一個帳號,誰都可以去畫地圖、改地圖,在沒有自動檢核機制之下,靠的是圖客們的檢視,愈多人使用,正確就會愈高,就和開放源碼一樣,符合所謂的Linus’s Law (given enough eyeballs, all bugs are shallow)。TeleNav捨棄了與TomTom合作,敢用群眾外包的圖資,顯示處理開放街圖到導航可使用的水準之成本己經不高,與其花錢去買地圖公司的圖資,倒不如把錢拿來處理開放街圖,讓自己的公司充份地掌握自己的LBS服務商品中的地圖,不用只與一家地圖公司合作,地圖圖資被一家公司所掌握。所以TeleNav在今年(2014年)1月底先以2千4百萬美元買下在德國柏林的新創公司Skobbler,其實就是想買進轉換開放街圖資料的技術,就更不用說,Steve Coast在去年(2013年)9月從Microsoft跳槽到TeleNav,早早在為使用開放街圖做準備。

地圖內容己經不是單純地是單一地圖公司提供就可以滿足現今適地性服務(LBS),Google在去年(2013年)6月也是約13億美元天價買下以色列的LBS新創公司其目的就是提供地圖與用戶互動服務,讓用戶可以透過地圖的使用能回饋到Google Map,而能讓地圖內容更符合用戶需求,當然戰略上也是為了Waze不讓Facebook或Apple給拿走,去擴增適地性服務(LBS)。 適地性服務(LBS)與社群媒體(social media)二者己經是密不可分,一方面,地圖內容如何透過社群媒體結合更多用戶來改善地圖內容、提高更新速度,另一方面,如何透過地圖使用行為,來改善適地性服務(LBS)方式,以提供更貼近人心的地理服務,無論如何,用戶才是決戰的重點,Waze號稱他們在全球有5千萬個用戶,而開放街圖呢?2014年開放街圖的全球註冊的用戶已經達160萬人,這個數量與Waze顯然有很大的差距,但二者用戶的本質是相當不同的,開放街圖註冊用戶是地圖的貢獻者,不是單純的使用者,反觀有多少人在Waze上貢獻資料呢?TeleNav當然看上這點,上那找這麼多的地圖貢獻者來繪製、編修地圖,開放街圖的社群成自然而然成為最好的後盾。

TeleNav使用開放街圖的案例,事實上就是一個開放資料成功的應用案例。就TeleNav而言,TeleNav花的錢並不是買圖資,而是技術,TeleNav所省下的成本可以用來增強導航功能,而使得他們的產品在市場上更有競爭力,另一方面,開放街圖並沒有因為TeleNav或其它廠商的使用,而更動它本來既有的運作方式,從繪製編修地圖到社群的活動都不會因為這樣而改變[註1]。一樣的道理,在談開放政府資料加值或者是產業,就是在於開放政府資料如何省去廠商資料成本,而能專注地在於技術服務的開發,這對於新創公司其實是大利多的,因為過去政府許多資料不是很貴,就是開放授權講不清,往往是有管道、有關係、大資本的公司才可以拿到資料,透過政府開放資料,免除了這樣的問題,新創公司能專注於資料使用上的創意,而不是在資料取得就己經先吃癟,怎麼能夠期待有創意,更沒辦期待像Skobbler這樣的公司出現。

因此開放街圖所開創的經濟模式,有別於以往Google Map的模式,各位可以看看,在最近5年來的競合之下,走Google Map模式的地圖商、導航商,其實只剩下Google Map了,不但國際大廠連連整併,就連Local的地圖服務商也很難掙下去,台灣有UrMap呀! 現在有多少人還用?我相信TeleNav的案例一定會帶給許多人啟發,但走開放街圖的模式是否能夠成功,這無法保證,但絕對會是另一個機會,隨著開放街圖的成熟,一定會有愈來愈多人拿來商業使用,逐漸成為有別於Google Map模式的競爭者。

[註1]有中國人前陣子頻頻大規模的修改地圖,把台灣的地名都改成簡體了,猜想和TeleNav在中國也有分公司,要在中國地圖產品,必需符合中國法律有關

建議國土測繪中心之圖資開放

投書國土測繪中心主任信箱之內容如下:

貴 中心所製作之「國土測繪圖資網路地圖服務系統」內容豐富詳實,為符合Open Data潮流,其服務系統又以WMTS方式提供地圖的介接,實為難能可貴之地理資訊資源。

國際上目前有一項「開放街圖」(OpenStreetMap, OSM)之運動,為志工透過協同合作之方式編繪地圖所成,而編繪地圖過程中需要大量地理資訊做為地圖繪製之參考,OSM中之編輯器可以透過WMTS方式介接貴 中心之服務,成為繪製地圖之來源,唯服務系統中之地理資料尚未以開放授權方式釋出,且「使用條款」中之規定也無法保証,若OSM社群志工透過WMTS方式介接,來描繪地圖,是否造成對地圖使用之侵權,或剽竊地圖內容之嫌?

OSM為自由開放之地圖,且不是以營利為目的的製圖活動,這符合使用條款中之第四點,OSM並非是負面列舉項目之一,但第一點中強調透過Web Maps API服務取得地圖圖片檔,但不代表取得著作權,因此貴 中心所保有著作權只允許使用者透過Web Maps API去「看」或欣賞地圖,OSM製圖行為涉及描繪,就著作權定義而言,OSM的志工若使用貴 中心之地圖恐造成侵權。建議貴 中心是否參考Creative Common之授權方式,讓貴 中心保有著作權,並可讓Web Maps API發佈之資訊在使用上更彈性、更廣為使用,而更符合Open Data之潮流,讓使用者免於侵權之恐。

===============================

國土測繪中心之回覆:

有關本中心國土測繪圖資網路地圖服務系統」(以下簡稱本系統)基於OpenData潮流,提供開放之WMTS服務供各單位介接加值應用,而本中心之主要圖資如通用版電子地圖,係依「測繪成果電子資料流通作業要點」對外收費供應的圖資,未在免費供應之列,先予敍明。
     因此「開放街圖」OpenStreetMap,OSM如以直接介接本系統的圖資為底圖,則符合使用條款中的第4點,而且使用者看到的將是最新的圖資。您所提及Creative Common授權(CC)方式,目前並未在相關規定中規定,本中心未來將研議是否可納入Creative Common授權方式。

===================

後記,國土測繪中心於104年07月09日己經將精簡過的通用版電子地圖以「政府資料開放授權條款-第1版」釋出。

10個政府資料不願意開放的的理由

因為要去參加一場與開放資料相關的會議,於是乎,列了10個政府資料不願意開放的的理由。
1.資料涉及國防、社會安全議題敏感
2.資料涉及個人隱私
3.擔心資料品質不好,怕開放後被質疑
4.擔心資料被外國公司使用,有資訊外洩之嫌
5.擔心被外界誤用,如石虎的調查資料怕被反「13線拓寬工程」的人看到
6.主張智慧財產權,例如資料生產單位有著作人格權
7.資料為財產,怎麼可以隨便給你用
8.因為規費法,要付費後才可以拿到資料
9.沒有適宜的法令讓我們的資料開放
10.你就用嘛! 不要問這麼多

連結感測器資料(Linked Sesnor Data): 從氣象測站到連結資料

緣起

會進行這個Linked Sesnor Data的試作有一些緣由,把時間拉回2013年8月1日在環保署召集的「環境資源資料開放專家諮詢會議」,開會目的除了討論環保署資料開放平台,更是在於討論紫外線測站資料來當開放資料五顆星的範例。太酷了! 環保署願意進行開放資料5顆星的示範是一件很棒的事! 不但有助於環保署所屬開放資料品質的提昇,也可以刺激其它政府部會對於開放資料品質的關注。但會中業務單位所簡報的那個「紫外線測站的五顆星開放資料」是問題多多,對於OWL/RDF有了解的人,其實不難發現簡報中的那份RDF是有問題的,況且把資料編譯為RDF格式充其量就是4顆星等級,怎麼可以說是5顆星呢?再者,所謂的5顆星開放資料是要連結什麼呢!?

這個問題後來成為與會專家要給予的答案。資料集與資料集要連結,這之間就必需要有某一些關連,也就是所謂的context,以致於資料集中的某一個entity可以與另一個entity以某種形式相連,在普遍的做法就是用owl:sameAs來表達在不同資料集中的二個entity是一樣的,以我有限的所知,資料集之間的context可以由三個特性來思考: 地理空間(Geospatial)、時間的(Temporal)、和主題屬性的(Attributiive),以環保署開資料平台中的紫外線測站資料為例,有可能連結的部份看來只有地理空間的特性了! 就資料特性而言,若環保署要做Linked Open Data (LOD),建議應該朝向Linked Sesnor Data,就是把所有測站以OGC的Sensor Web Enablement (SWE)W3C SSN Ontology 二者來表達環保署中的測站,而測站所產生的資料則是以Linked Observation Data 來詮釋。

 

IMG_20140103_121214從Sesnor nodes組成sensor network,然後以OGC SWE來架構Sensor Web,所以容易再以W3C SSN Ontology表達

 

IMG_20140103_121156Linked Sesnor Data, Linked Observation Data, and Geonames

 
很遺憾的是,他們並沒有採納這些意見,在環保署開放資料平台上線後,12月初無意間看到,那個有問題的說明己經在環保署開放資料5顆星的頁面上,而有問題的RDF資料也提供下載。這種做法給了二個不好的示範,首先,在專家會議中,本人就不認為那是對的說明和對的RDF資料,但這些內容和資料還是上線了,好吧! 意見也給了,那專家會議的用意什麼? 另一個是比較嚴重的問題是,把錯誤的LOD說明和資料放在一個政府公署開放平台的網頁上,很容易就會誤導其它人,對於LOD的理解,開放也得開放「對」的資訊,是吧! 身為市井小民所幸可以透過平台「意見回饋」反應機制,向環保署說明,那份說明的LOD頁面和RDF資料有問題,哈! 意見回饋比專家會議有效耶! 環保署在一週後拿掉在資料開放平台上的那些LOD資料,所以大家己經看不到了,接著承辦這項業務的人員也來拜訪,並帶著修改的RDF來討論。的確,修改後的RDF,使用了標準語彙,如Dublin Core,但看起來就是一份單純由表格轉為RDF的文件,這不見得有錯,但語意的表達是相當弱的,對於紫外線測站詮釋,也就是紫外線測站所表達出的概念是什麼?並沒有辦法得知。

或許,你心中油然而生一個問題,「疑!那些LOD的資料,在網頁看起來都像是表格一樣,那資料轉成這樣有什麼問題?」嗯! 那些LOD的資料背後其實都有一個ontology來表達資料的語意,只是放上網頁為了瀏覽方便而表現成表格的形態,利用標準語彙也是在確保資料語意不被誤解,但ontology中,概念的結構和邏輯的規範可以使資料語意更為完備,並可以進一步達到邏輯推理,當然目前我們只需要達到將資料本身概念充份地表達,在這個紫外線測站的案例中,如同前面所說,還是採用W3C SSN Ontology來表達紫外線測站才是比較恰當的方式。

從建構知識本體(ontology)開始

這筆所謂的紫外線測站基本資料所記述的資料相當有限,主要項目如下:

  • 紫外線測站的中英名稱
  • 紫外線測站所在的縣市鄉鎮
  • 紫外線測站的空間座標和住址
  • 紫外線測站的發佈機關

這筆有限的資料能表達出的內涵確實不多,若只根據這些項目編出的ontology應該也很空洞,對於一個用來表達紫外線測站的ontology而言,不僅僅是要表述地理空間的描述,更重要是要表達什麼是紫外線測站和紫外線測站觀測什麼。根據W3C SSN Ontology 對於感測器(Sesnor)的描述和定義,可以重新想想,要如何重新表達這筆紫外線測站資料:

  • 紫外線感測器本身是用來測量紫外線(Ultraviolet)的
  • 紫外線觀測是以紫外線指數(UV Index)
  • 紫外線感測器是裝在中央氣象局的氣象站或環保署的空氣監測站
  • 無論是氣象站或空氣監測站都有空間座標、地址、和所在行政區域

W3C SSN Ontology 這份報告附有很多案例是可以依循的,其中對於Linked Sesnor Data 就有一個案例,對於紫外線測站資料,不就是一個很好拿來模仿的案例! 對於感測器(Sesnor)的描述和定義,這個案例中主要使用W3C SSN ontology和DUL(DOLCE Ultra Light) ontology,此外也描述感測器(Sesnor)觀測能力和裝在氣象局的事實,更重要的是這樣表達的感測器(Sesnor)是可以被連結(link)。根據這個架構,可以設計一個ontology來解釋這筆紫外線測站資料,而這個ontology 不單單只有紫外線測站的ontology,而應該是感測器知識本體(sesnor ontology),且可以應用在任何不同的感測器上,我習慣先用畫圖把需要的class和individuals先勾勒出來,以便後續ontology的編輯。

uv_ontology根據W3C SSN 和 DUL設計的紫外線感測器ontology

 
與寫程式類似,ontology的編輯可以用文字編輯器,但也有一些工具輔助,一般常用的工具為Protégé,根據上面那個畫好的圖,這個UV sesnor ontology 很快就能完成。
 

Linked Data: 讓自己可以被連結,也可以連結別人

一一解釋UV Sesnor Ontology中類型(class)和個體(individual)會是冗長的說明,為了有效率的說明UV Sesnor Ontology中的知識表達,以下是擷取部份段落來做解釋:
 

Solar501A (亂瞎掰的)感測器本身是用來測量紫外線(Ultraviolet)的,安裝於台北氣象站的系統平台上,且有量測紫外線指數(UV Index)的能力,而紫外線指數有15個等級,每一個等級就是100焦身/每平方公尺,例如8就是測到紫外線800-899焦身/每平方公尺。紫外線指數又可以分級為低量級、中量級、高量級、過量級、和危險級,下面案例只顯示紫外線指數8-10是過量級。

 

###  http://lod.tw/ontologies/weather-station/uv#Sensor_Solar501A

:Sensor_Solar501A rdf:type ssn:SensingDevice ,
                           owl:NamedIndividual ;

                  ssn:onPlatform :Platform_for_Taipei_Weather_Station ;

                  ssn:hasMeasurementCapability :UV_Index_MeasurementCapability .

###  http://lod.tw/ontologies/weather-station/uv#UV_Index_MeasurementCapability

:UV_Index_MeasurementCapability rdf:type ssn:MeasurementCapability ,
                                         owl:NamedIndividual ;

                                ssn:inCondition :UV_Sacle ;

                                ssn:forProperty :Ultraviolet .

###  http://lod.tw/ontologies/weather-station/uv#Ultraviolet

:Ultraviolet rdf:type ssn:Property ,
                      owl:NamedIndividual .

###  http://lod.tw/ontologies/weather-station/uv#UV_Sacle

:UV_Sacle rdf:type ssn:MeasurementRange ,
                   owl:NamedIndividual ;

          ssn:hasValue :UV_Index_0_interval ,
                       :UV_Index_10_interval ,
                       :UV_Index_11_interval ,
                       :UV_Index_12_interval ,
                       :UV_Index_13_interval ,
                       :UV_Index_14_interval ,
                       :UV_Index_15_interval ,
                       :UV_Index_1_interval ,
                       :UV_Index_2_interval ,
                       :UV_Index_3_interval ,
                       :UV_Index_4_interval ,
                       :UV_Index_5_interval ,
                       :UV_Index_6_interval ,
                       :UV_Index_7_interval ,
                       :UV_Index_8_interval ,
                       :UV_Index_9_interval .

###  http://lod.tw/ontologies/weather-station/uv#UV_Index_8_interval

:UV_Index_8_interval rdf:type DUL:Region ,
                              owl:NamedIndividual ;

                     :hasMeasurementPropertyMaxValue :UV_Index_8_max_value ;

                     :hasMeasurementPropertyMinValue :UV_Index_8_min_value .

###  http://lod.tw/ontologies/weather-station/uv#UV_Index_8_max_value

:UV_Index_8_max_value rdf:type DUL:Amount ,
                               owl:NamedIndividual ;

                      DUL:hasDataValue "8.99"^^xsd:float ;

                      DUL:isClassifiedBy :Hecto_joule_per_square_meter .

###  http://lod.tw/ontologies/weather-station/uv#UV_Index_8_min_value

:UV_Index_0_min_value rdf:type DUL:Amount ,
                               owl:NamedIndividual ;

                      DUL:hasDataValue "8.0"^^xsd:float ;

                      DUL:isClassifiedBy :Hecto_joule_per_square_meter .

###  http://lod.tw/ontologies/weather-station/uv#Very_High_Risk

:Very_High_Risk rdf:type ssn:FeatureOfInterest ,
                         owl:NamedIndividual ;

                rdfs:label "過量級"^^xsd:string ;

                ssn:hasValue :UV_Index_10_interval ,
                             :UV_Index_9_interval ,
                             :UV_Index_8_interval .

 

台北氣象站的系統平台是台北氣象站的一部份,台北氣象站是中央氣象局的一部份,而台北氣象站和中央氣象局都是一種組織(Organization)。

 

###  http://lod.tw/ontologies/weather-station/uv#Platform_for_Taipei__Weather_Station

:Platform_for_Taipei__Weather_Station rdf:type ssn:Platform ,
                                               owl:NamedIndividual ;

                                      ssn:attachedSystem :Sensor_Solar501A ;

                                      DUL:hasLocation :Site_Taipei_Weather_Station ;

                                      DUL:isPartOf :Taipei_Weather_Station .

###  http://lod.tw/ontologies/weather-station/uv#Taipei_Weather_Station

:Taipei_Weather_Station rdf:type :Weather_Station ,
                                 owl:NamedIndividual ;

                        rdfs:label "Taipei"^^xsd:string ,
                                   "台北"^^xsd:string ;

                        DUL:isPartOf :Central_Weather_Bureau_Taiwan ;

                        DUL:hasLocation :Site_Taipei_Weather_Station .

###  http://lod.tw/ontologies/weather-station/uv#Weather_Station

:Weather_Station rdf:type owl:Class ;

                 rdfs:subClassOf DUL:Organization .

###  http://lod.tw/ontologies/weather-station/uv#Central_Weather_Bureau_Taiwan

:Central_Weather_Bureau_Taiwan rdf:type :Government_Organization ,
                                        owl:NamedIndividual ;

                               rdfs:label "中央氣象局"^^xsd:string .

 

台北氣象站是在台北氣象站場址(site),這個場址是一個地方(Place),有一個WGS 84 XY座標的參考點(reference point),且這個場址有一個地址(Address),這場址也在一級行級行級區的台北市之中和二級行政區的大安區之中,且大安區也在台北市之中,而台北市在台灣之中。

 

###  http://lod.tw/ontologies/weather-station/uv#Site_Taipei_Weather_Station

:Site_Taipei_Weather_Station rdf:type DUL:Place ,
                                      owl:NamedIndividual ;

                             geo:hasGeometry :Reference_Point_Taiepi_Weather_Station ;

                             vcard:hasAddress :Address_Taipei_Weather_Station ;

                             :is_in :Daan_District ;

                             :is_in :Taipei_City .

###  http://lod.tw/ontologies/weather-station/uv#Reference_Point_Taiepi_Weather_Station

:Reference_Point_Taiepi_Weather_Station rdf:type geo:Point ,
                                                 owl:NamedIndividual ;

                                        wgs84_pos:long "121.55834"^^xsd:float ;

                                        wgs84_pos:lat "22.036934"^^xsd:float ;

                                        geo:asWKT "Point(121.5583420000, 22.0369330000)"^^sf:wktLiteral .

###  http://lod.tw/ontologies/weather-station/uv#Address_Taipei_Weather_Station

:Address_Taipei_Weather_Station rdf:type owl:NamedIndividual ,
                                         vcard:Address ;

                                vcard:street-address "公園路64號"^^xsd:string ;

                                vcard:locality "台北市"^^xsd:string ;

                                vcard:country-name "台灣"^^xsd:string ;

                                vcard:region "大安區"^^xsd:string .

###  http://lod.tw/ontologies/weather-station/uv#Daan_District

:Daan_District rdf:type lodtw:2nd_Administration ,
                        owl:NamedIndividual ;

               :is_in :Taipei_City ;

               owl:sameAs freebase:Daan District ,
                          geonames:Daan District .

###  http://lod.tw/ontologies/weather-station/uv#Taipei_City

:Taipei_City rdf:type lodtw:1st_Administration ,
                      owl:NamedIndividual ;

             :is_in :Taiwan ;

             owl:sameAs freebase:Taipei ,
                        geonames:Taipei ,
                        wikidata:Taipei ,
                        depedia:Taipei.

 
眼尖的你不難的不發現,上述的每一個「類型(Class)」和「個體(individuals)」都是以URL方式呈現,如http://lod.tw/ontologies/weather-station/uv#Taipei_City; 且上一段中的台北市和大安區都己經以owl:sameAs分別連結到DBPediaGeonamesWikidata、或Freebase,如UV sesnor ontology中的Taipei_City是以owl:sameAs連結http://rdf.freebase.com/ns/m.0ftkx, http://sws.geonames.org/7280290/, http://www.wikidata.org/entity/Q1867, 和http://dbpedia.org/resource/Taipei。與一開始所做的分析一樣,在這筆資料中地名是最有可能拿來連結其它資料的實體(entities)。

最後,想強調的是,編寫這個UV Sesnor ontology用意在於讓更多人了解什麼是LOD,並期待能引發更多LOD的討論,而能有更多更正確的LOD資料。

各國在開放地理資料(Open GeoData)發展的一些觀察

花了一些時間,看看幾個開放資料(Open Data)先進的國家,對於開放地理資料的做法,希望對於開放地理資料有興趣的人可以激發一些想法和互動。

1.美國

在美國由聯邦政府所轄之地理空間資料是免費且以公眾領域(Public Domain)的狀態釋出,也就是這些資料原則上已不受到法律的任何保護,使用者可以拿來做任何他喜歡的事,甚至是拿來販售,或者衍生出更有價值的資料來牟利。世人較熟知的資料,如美國人口調查局 (US Census) 的 TIGER 即是此類。此外,因為 geodata.gov 已經整併入 data.gov,在 data.gov 網站上目前也匯集有大量美國聯邦政府釋出的地理資料,除了聯邦政府,亦有各州政府、大學研究機構、非營利組織和其它機構等,提供不同來源的地理資料,這些資料可能也會以不同的開放授權方式在data.gov中釋出。

由於美國州政府具有極高的地方自治地位,各州政府對於地理資料開放的態度可能會相當不同,州政府所收集或生產的地理資料亦可能會有不同的商業應用模式,加州政府即是一個顯著案例。〈加州公共檔案法」(California Public Records Act, CPRA) 規定加州州政府和各地方政府必須提供給任何需要公部門資料的人,且只能收取不超過資料複製成本的費用。加州司法部長根據資料主管單位的意見將數值地籍圖 (digital parcel basemap) 歸在加州公共檔案法下管理。倡議言論自由的非營利團體「加州第一修正案聯盟」(California First Amendment Coalition, CFAC),向聖塔克拉拉郡 (Santa Clara County) 政府以複製資料成本來申請數值地籍圖時,被該郡政府拒絕,CFAC 轉而至加州最高法院提起訴訟,結果最高法院認為郡政府數值地籍圖符合公共檔案法規定,應該提供公眾使用且只可以收取複製資料成本,這個裁決成為美國開放地理資料推動上的重要案例,這個事件的始末可參考OpenDataConsoritum的記錄。

2.英國

過去英國中央政府的地理資料和其它地方政府生產的資料一樣都受到皇家版權 (Crown Copyright) 的保護,使得地理資料無法被免費使用、再製和散布,事實上,開放街圖(OpenStreetMap)就是因應這個受限的制度而發展出來。受到開放資料運動的影響,英國測繪局於2010年4月啟動 OS OpenData 服務,這項服務中的地理資料是由英國地圖集中選擇常用項目來開放,如行政界線和郵遞區號,這些資料可作商業或非商業使用沒有任何限制。在 OS OpenData 的地理資料是以 Open Government License for Public Sector Information 的方式釋出,其授權方式與 Open Data Commons Attribution License (ODC-By) 相似,但對於資料提供者的角色宣告更為明確,且清楚指出那些資料不在授權條款的拘束範圍內,更重要的是對於所釋放的資料若有錯誤,亦註解了相應的免責聲明,這與英國過往的傳統作法大不相同。現在 OS OpenData 的資料也整併入 data.gov.uk。此外,英國測繪局也著手將地理資料依照「資料連接」(Linked Data) 的原則,將地理資料以「開放資料連接」(Linked Open Data) 定義的方式進行發布,如具有行政界線的英國地名資料即為一例。

3. 加拿大

GeoBase 是加拿大聯邦政府的計畫,採用 GeoBase 專屬的使用者條款 (GeoBase Unrestricted Use Licence Agreement) 來釋出地理資料以提供公眾使用,同樣以路網資料為主。GeoBase 中的路網圖主要是加拿大道路資料,其基礎的授權架構與著名的社群共工地理資料專案 OpenStreetMap 有許多相似的地方,兩者皆沒有限制資料的使用目的,但在資料再散布上的規則卻是不盡相同。GeoBase 條款對於使用者再散布資料時僅要求姓名標示 (atttribution) 這個基礎義務,但如繼續使用 GeoBase 的方式來散布,則此散布行為是不能收取授權金費用的,而如果使用者決定不再全盤依循 GeoBase 的既定授權方式來散布地理資料,那其亦可以將相關資料的授權模式轉為自訂的其他方式。因此,GeoBase此種得以轉換授權條款的模式,對於商業使用可能較為友善,商業公司可以利用GeoBase 釋出的相關地理資料來產出衍生作品,同時更改後續授權的條件以進行專屬性質 (exclusive) 的販售模式(Saunders et al., 2012)。

4. 澳洲

「昆士蘭政府資訊授權架構」(Queensland Government Information Licensing Framework, GILF) 是由「昆士蘭空間資訊委員會」(Queensland Spatial Information Council) 所提出,目的在於簡化公部門資訊的使用權利,GILF 可供選擇的授權模式,包含6款創用CC的核心授權模式,以及一項限制性授權的模式 (Fitzgerald, 2010)。一開始只有昆士蘭政府關注公部門資料的開放授權議題,在逐漸推展之後,如今澳洲各地方政府皆以「澳洲政府開放存取和授權架構」(Australian Governments Open Access and Licensing Framework, AUSGOAL) 的方式來作為資料提供上的參考基礎。

5. 荷蘭

在荷蘭的基礎設施和環境部 (Ministry of Infrastructure and the Environment) 收集的地理資料中,有些可免費取得,但授權方式有待釐清。事實上,荷蘭政府的許多地理資料是收費的,如大比例尺地形圖 (Grootschalige BasisKaart Nederland, GBKN)。但是,在荷蘭的 OpenStreetMap 專案社群成員的請求下,荷蘭政府在2012年1月起陸續開放了地籍資料、道路資料、和郵遞區號等重要的地理空間資料,以「創用CC 姓名標示 3.0」的方式釋出,這些資料總值據評估可達5萬歐元,其同時也釋放衛星影像,允許使用者對這些影像進行下載和重製,在荷蘭太空事務辦公室 (Netherlands Space Office, NSO) 的衛星影像服務平台上可以接觸到這些資料,我國福衛二號所攝製的相關資料也在收錄之列。

6.德國

德國聯邦地圖測繪局 (Bundesamt für Kartographie und Geodäsie, BKG) 於今年(2013)的4月9日宣布將 1:250000 的數值土地利用圖,和相類於此的數值地形圖以開放資料的方式釋出,此一舉措為德國聯邦政府的開放政府倡議 (Open Government Initiative) 提供了重要的貢獻。以大方向進行觀察,德國聯邦政府為推動開放資料,配套修改了「地理資訊取用辦法」 (Geodatenzugangsgesetz, GeoZG) 及其補充辦法 (Verordnung zur Festlegung der Nutzungsbestimmungen für die Bereitstellung von Geodaten des Bundes, GeoNutzV),此舉使 BKG 所釋出的資料,得以採行符合開放授權精神的模式來被使用。

7.日本

日本的產業和學界相當支持開放資料活動,以產學為主共同舉辦了一系列「日本連結開放資料挑戰」(Linked Open Data Challenge) 的活動,促進日本政府對於開放資料的著力與推動。日本國家等級的政府地理資料可由國土交通省國土地理院取得,日本政府也每年編列預算給國土地理院進行地理資料的測量、收集,與維護。由「地理空間情報活用推進基本法」和「地理空間情報活用推進基本計畫」來看,日本政府公部門所轄的地理資料,是可以讓民眾以合理的價格取得。值得一提的是,在2012年於日本東京舉辦的全球性 OpenStreetMap 研討會(State of the Map, SotM 2012)中,國土地理院地理空間情報部長村上廣史 (Hiroshi Murakami) 在會中特別述明與日本 OpenStreetMap 專案社群的合作,讓國土地理院的資料可以被 OpenStreetMap 專案所使用,而國土地理院也可以利用OpenStreetMap 專案自主維護的資料,來進行其轄下管理圖資的除錯與更新。

特別感謝 lucien.cc 和trc對本文中部份文字做適度的修正。

Enhanced by Zemanta

2013-05-04 Open Data Meetup 一些心得 — 開放資料的目的是在於透明化

感謝Whisky號召讓大家在週末前來個Meetup,也感謝David提供場地準備點心零食。網路上的召集,昨天晚上聚集了來自各界的17個人的參與,MnO2快筆寫下這個meetup記錄,在這裡來分享一下個人的一些心得。

因應政府資料開放平台( data.gov.tw) 公測版的上線,這個meetup想讓大家聚在一起討論這個平台的問題,和未來對政府開放資料的期許。研考會似乎想知道和民眾期待的落差有多少? 但來這裡接收這些訊息的人是來自於凌網科技?我的困惑是凌網科技與研考會的關係為什麼要搞的如此的如膠似漆?可以做這個平台的廠商或NGO組織應該不少,凌網應該不是唯一吧!?但這個平台下一期仍然會由凌網得標? 有沒有人可以揭露一下為什麼凌網科技是研考會的唯一? 研考會為什麼選凌網科技來承包開放資料的平台的業務?廠商有什麼能力與資格才能承包這種業務?是不是很多人和我一樣想知道? 因為無「知」,請原諒我在談論中一直吐糟這位來自於凌網科技的朋友。

聚會中有不少人不認為在meetup中各自提出「政府應開放的10種資料」,政府的就會如實開放?我的反應很直接,以地籍資料而言,目前就是一個不可能的任務,因為這個資料是地方政府財源之一,對於開放的反對聲音會很大,內政部國土測繪中心若想開放還得有一段很長溝通過程。而許多與公部門交手過的與會者也多少了解基層的資料業務單位面對開放資料問題和困惑,若他們想談,許多資料使用者也願意溝通,而不只是一昧批判,因此重點在於能不能建立這樣的溝通機制?如英國政府資料開放平台(data.gov.uk)有data request 的功能,使用者若找不到可以利用data request來要資料,這個需求會被送到資料的業務單位,資料是否開放的處理過程和溝通皆公佈在平台上,其他對於這個資料有興趣的人就也可以知道處理清況,事實上,CfThellodata也在蒐集這樣的經驗。若這個資料的開放真的對於社會公益有幫助,在這樣公開的討論下,資料業務單位也會面臨極大的民眾輿論的壓力,回到地籍資料,若多數人覺得這是一件極需要開放的資料,如在Facebook上,大家都來按「讚」,地方政府也會感受壓力,我們的代議士們也才會感受「民氣」(選票),進而觀切,好啦,這個太理想了!?

開放資料社群也意識到這點,在做自已的「平台」表達開放資料的期許,展示對開放資料的處理能力,如零時政府的data.g0v.tw、經由網絡行動科技(Netivism)中譯且調校的CKAN,在青平台架起的台灣資料開放平台、 Cft再整理台北市政府的開放資料放在github上,從這裡長官們不難發現社群要的是什麼樣的平台和資料吧?!

總之,開放資料的目的是在於透明化,也就是人民有「知」的權利,無論平台,還是request的機制,都得在一個透明化過程進行。個人相當期盼有一個建全的開放資料平台,且該平台有資料request 的機制,提供民眾請求資料開放,且處理過程能透明化公開,再一次,好啦,這個太理想了!?

快篩「政府資料開放平台(公開測試版)」

一個開放資料平台是施政者用來證明政府開放程度的最佳方法之一,政府開放資料平台的成立是為了邁向透明化政府,讓人民看得到,而且「有感」! 因此透過人民使用政府所開放的資料,一方面,人民可了解政府施政、參與政府政策、甚至提出建言,使政府更有效率;另一方面,人民亦可利用政府所開放的資料,經由自己的創意與加值,從這之中獲利,政府即透過資料的開放而創造就業機會增加民間產值。

順應世界Open Data 潮流,研考會終於成立了「政府資料開放平台」(data.gov.tw),讓台灣達到Open Data的一個里程碑,恭禧! 但快速地瀏覽這個平台後,有「感」!感受到台灣政府對於透明化政府的害怕、抗拒與掙扎:

  • 過度本位主義的「政府資料開放平臺資料使用規範」。使用規範,或者說是該平台上的資料授權,主要是用來確保資料使用者在散佈、重製和改作該平台上資料時,不受智財權的限制;另一方面,政府釋出資料,恐怕因為有人用了這些開放資料後,造成財產或權益上受損,因此都會有免責聲明,這些都可以理解,但在使用規範中,聲明各機關可以停止提供資料,是一件值得商榷之事。政策改變而導致資料提供不符公共利益?我還想不出來有什麼樣的例子會有這樣的情況發生。而資料開放前,各機關就得清查所開放的資料是否涉及他人智財權、隱私和國防安全考量,怎麼會在開放後,因查覺到這些問題,才說不開放?這是為各機關不願意在開放前清查資料脫責?

六、開放資料停止提供 

有下列情形之一者,各機關得隨時停止全部或一部開放資料提供,使用者不得向本平臺管理機關及各機關請求任何賠償或補償:

(一) 因政策變更或其他正當事由,致各機關認為繼續提供資料供使用者加值使用,已不符合公共利益之要求者。

(二) 各機關開放之資料有侵害第三人智慧財產權、隱私權或其他法令疑慮

  • 重複開放、授權不一。「產銷履歷」為農委會項下的開放資料,是以CC 3.0-BY-SA方式釋出,但研考會把它再收入一次,但研考會的授權規範可以淩駕於CC授權?根據上述第6條,若政府因某些原因要停止開放產銷履歷,但早以CC釋出的資料是不能這樣被停止。
  • 人民不笨! 資料筆數多寡不會是用來評估平台的好壞的唯一指標,令人有感的資料才是符合人民期盼。當我看到「鐵路時刻表」和「客運時刻」時,著實地讓我倒抽一口氣,讓我驚訝政府透明的態度,時刻表還要開放嗎?本來就應該是開放的資料,難道在資料沒放上此平台前,交通部不允許火車時刻表被使用? 這只是多提供一個資料接口罷了!當然就不用說,資料提供只是為符合上級要求的各單位5項,因為教育部把大學、中學、小學、幼稚園的住址拆開,就有好幾個表,夠交差了!這樣的情形在台北市開放資料平台也有,OK認證也用產業別被拆成好幾個表,等著看吧!這種情形應該會不斷發生。
  • 沒有資料視覺化功能,當然就不可以有分析功能。目前Open Knowledge Foundation所建議的資料開放平台(CKAN),在資料上傳至平台後,可以將表格化的資料利用open source 的JavaScripts,將資料呈現,好驚訝!一個國家級的資料平台,是以這麼raw的資料呈現。
  • 資料編碼.地理座標格式不統一,增加使用者困擾。BIG 5 –> UTF8, TWD97TM2 –> WGS84 Lon/Lat

 

鏈結資料 (Linked data)、開放資料(Open Data)和鍵結開放資料(Linked Open Data): 從學術到產業行與不行?

昨天應「高人」之邀,參與了台北市電腦公會舉辦的第三場 Open Data產業新契機系列論壇,會中的提問,好像講了太多我們過去的做LOD的經驗,但我提出問題的可能不是很精確,所以台上沒有任何回應,會後也沒有進一步的討論,只有台北市議會的人,是周柏雅議員的助理嗎? 說如果台北市的資料有這樣的問題我們可以幫你,感恩啦! 因為說的不好,所以在自己的部落格上解釋一下。我的發言應該是這樣的

本人在LOD上有實作,有一些經驗可以分享。研考會陳怡君科長說得好,政府資料中有74%是與地理資料有關,地理資料的開放與LOD的發展有很大的關係,今天就以地名而言,是一個很好的鍵結資料,如大家知道「野柳」過去被西班牙人稱為Diablo,這就是同一地點在不同時間上的對於地方稱呼的鍵結,也是台灣與西班牙的鍵結,地名資料目前是沒有公開授權的資料庫,中研院生物多樣性中心和農委會林試所,已經就利用他們所建立的4 5個資料庫中的資料透過開放授權,將資料釋出後,再以LOD技術與全球資料庫GBIF鍵結,並上傳到datahub.io被審核後成為LOD cloud的一雲,而我以內政部地名資料為主,做了另一個LOD的資料集已經與全球最大的地名資料庫Geonames.org 連結,並沒辦法完全上傳至datahub.io,原因是台灣地名資料庫沒有公開授權,若我上傳即有法律上責任,目前只能以學術研究方式提供參考。

(發言的內容有做過一些修飾,但大意沒變。哈哈哈,當天下午已經是疲憊不堪,在沒有充足的提精飲料下,實在無法完整的想起來我說了什麼。TCA的人在我發言完後,拿了一張紙來叫我把我的發言寫下來,幹嘛!這是小學生考試嗎?TCA的大哥大姊別欺負我,請看上面不精確的回憶)

我的問題要表達一件重要的事情,資料沒有公開授權怎麼有辦法做LOD,若要說也只是Linked Data不是Linked Open Data,我長年關心的是地理資料開放授權議題,都到現在這個節骨眼上了,總不能還叫廠商花錢買? 但在場的人似乎不是很在乎這件事。

接下來,對於LOD在產業上的發展,有些觀察,因個人研究興趣,對於語意網和鍵結資料有一些經驗,但三年多來對於鍵結資料的研究,多是都在學習歐美國家發展的狀態,本身並沒有研發出了不起的理論或軟體,相信一定有人比我還專業,能夠說得上的,獻醜了,就是去年在一個日本舉辦的國際會議上,就如何利用LOD資源來做強化非結構性資料,讓使用者在Facebook上貢獻資料中的能夠與現存的LOD資料相連,發表了一篇文章,論文集會由LNCS出版,有興趣可以看看投影片內容

然而這一趟去了日本,學習不少,讓我驚豔的地方是日本對於Open Data的推動方式。學術團體、地方政府和民間業者共同推動Linked Open Data (LOD) Challenge,使得產官學能夠以Open Data的需求與供應面上,就資料集(Data set)、想法(idea)、應用程式(Application)、視覺化(Visualization) 等四個面向來做競賽,個人對於這個活動做了一個簡單的介紹,而觀察了幾個月下來發現,這樣子的競賽活動快速帶動政府、產業和學術的相互交流,強調的是Open Data資料真正落實資料應用的發展、從個人收集女性流行服飾資料並做成APP,到利用政府公開資料來發展生態或深度旅遊應用程式,對於Open Data的應用上,就廣度和深度都有一定的水準。

學術上的研究本來就應該落實到產業,但學術研究的人並不一定能夠了解產業的需求,藉由一次次名為“Challenge”活動,實際上是一種「溝通與對話」,可以逐步地媒合資料供給、技術研發和產業發展,TCA舉辦一系列論壇的目的和日本LOD Challenge相同嗎?老實說,在昨天的論壇中,我沒有看到LOD真正能夠落實到產業是什麼?先不論技術層面的問題,資料連不連的起來的問題,就「原住民族文化觀光資料開放」中的幾個Use cases,看起來就只是在消費原住民的文化,是以治理(或統治)者的角色在思考產業,但這或許是原罪,現存資料庫中的資料本來就是以治理者角度在建立資料,而不是保存文化的角度,舉一個簡單的例子,傳統領域可能與觀光不是那麼密切,但傳統原住民的地名,用他們自己語言來謂呼的地方的名字,是一個重要的文化資產,各位到蘭嶼,下飛機後,看到的地圖是漢語不是達悟族語,那他們為什麼不能用達悟族語來表達他們的地名?同樣的,玉山、雪山和許多高山可能都有布農族或泰雅族地名,為什麼沒有一個漢語和原住民語,雙語併行的地圖? 若原民會手上有原住民傳統地名,拿來和內政部地名Link一下,往後觀光業者就這個資料開發,就可以有雙語,可以行銷在地,又可以教育民眾在地知識,保存原民文化,(長官~,我希望看到的這樣的案例)。廣告一下,事實上,有一群長期關心原民文化的朋友(而且還有外國人參與,汗顏!外國人比我們還關心原住民),長期在花東一帶做原住民語輸入法,也逐步地將原住民語地名建入OpenStreetMap。

LOD的發展是技術面很吃重的工作,若要以推廣LOD進入產業,工具的研發或在化地是很重要的一環。目前在歐洲多是以歐盟層級的大型計畫,如FP7中的LOD2來做研發,並釋放許多的Open Source工具,使後續可以就他們的經驗和基礎再研發。但有許多工具,不一定適合於台灣的資料,最簡單,我們使用的是中文,和別人語系不同,在處理語意,和資料鏈結也會不同,(腦海中竟然出現肝藥廣告詞:成份不同、效果也不同),工研院扮演的角色是針對原民會的這個計畫研發工具,並釋放給業界使用? 昨天的簡報和問答,實在沒有辦法了解到這點。

LOD是達到開放資料五顆星等級的方法,是世界潮流與趨勢,很高興,政府單位開始想做著手做這部份,舉雙手贊同。但昨天聽起來,心中疑惑更多,這樣的討論充其量的只是一個Linked Data的論壇,而不是Linked Open Data的論壇,這麼多被提到資料,有多少是開放授權呢? 再者,談LOD進入產業是否太早,工具研發和人才培育是關鍵,我很懷疑目前台灣有多少技術人才可以進行LOD的工作,產業若要接手有多少工具可以使用?多少人才可以運用? 如果這二個基礎都沒有,LOD產業可能只是另一個空談。