開放街圖(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在中國也有分公司,要在中國地圖產品,必需符合中國法律有關

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

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

為什麼HTML不能實現語意網?

在網路搜尋資料時,最大的阻礙是資訊使用者與資訊提供者之間所使用的語意不同,如果使用者無法以 “正確”的語彙來搜尋,所得結果不是錯誤,就是眾多的搜尋結果中只有少量使用者想要的結果,以致於使用者無法擷取提供者的資訊,而提供者無法將資訊送達於使用者,這是因為搜尋工無法了解網頁中資訊的意義,為解決這樣子的問題 Tim Berners-Lee,全球資訊網(World Wide Web)之父,於2001年提出語意網的概念。在語意網中,在網頁中的文字與媒材會被連結到知識本體中相對應的概念或及其關係,而此知識本體中的概念是充份被定義,且概念中彼此的關係亦被清楚的說明,因此使用者在搜尋資料時,語意網的服務可以提供更為符合需求。
然而,目前網頁的技術—超文字標記語(Hypertext Markup Language, HTML)是無法達到語意網的實現,因為HTML的標記(tag)只針對網頁內容在瀏覽器中顯示的方式所設計,如台灣是說明台灣一詞在網頁中顯示為粗體,但可使用的標記限定於技術規格中所列,而另一種資料交換常使用的格式—可擴展標記語言(Extensible Markup Language, XML) ,雖然XML對於標記名稱沒有限定,著重於標記的結構,但這只使用資料具有語法上結構,而沒有達到語意層級。為實現意語網,W3C (WWW Consortium) 在XML的基礎上訂定了另一種具有語意的資料編碼方式,為資源描述架構 (Resource Description Framework, RDF),如class, subclassOf, property, subpropertyOf, domain, range, sequences, collections, 和其它一些相關語彙,資料經過RDF的編碼後,可所解析RDF的工具可了解資料的語意,如二個概念中具有一個subclassOf 的關係,可以知道這二個概念有上下從屬的關係,因此常被用來編寫簡單的知識本體,通常都是具有概念階層上語意關係。
更進一步,網路本體語言 (Web Ontology Language, OWL)則提供更多邏輯關係的定義來使資訊的語意更明白,包含函數化關係( functional properties)、反關係(inverse relations)、遞移性(transitivity)、同義字(synonyms)、基數限制(cardinality restrictions)和附加概念(additional concepts)。依照使用邏輯關係複雜程度,OWL三種版本可以使用,分別為 OWL Lite、OWL DL、和OWL Full。 OWL Lite 支持使用者定義分類層級的架構和簡單的限制; OWL DL中的DL即是描述邏輯(Description Logic),表示所使用的邏輯規則是以描述邏輯為基礎;而OWL Full 顧名意義即使用所有OWL的語彙,且有更多有彈性的定義,但目前多數工具或軟體不支援OWL Full所編碼的資料。語意網 (Semantic Web)將帶來Web 結構化有意義的內容,且開創了一個環境其中軟體代理人可以網頁到網頁間的漫遊,很容易地實現使用者所需的複雜任務(Berners-Lee et al., 2001). 語意網不是另一種Web而是現在的延伸,可使人與電腦再好的合作,在語意網的第一階段中結構化現存的Web己經在進行,未來這些發展應引導出重要新功能,而成為一種“機器”,使了解資料且更好地處理資料 (Berners-Lee et al., 2001)。

連結感測器資料(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資料。

利用Facebook的加速科學研究:群眾外包式魚類辨識

這是一個利用Facebook促進科學研究加快的故事。簡單地說,研究人員因為採集大量的魚類照片,自已辨識的話,得花費不少時間,因此計畫主持人的學生提議將照片放上Facebook將他們的朋友們來幫他們辨識這些照片,當然他們的朋友多數也是魚類或生物得家,而照片放上Facebook的24小時後,就有90﹪的照片已經被辨識,這個成功的故事就這樣登上了Science期刊!

Facebook的頁面

http://www.facebook.com/media/set/?set=a.1713096701121.243121.1049262482&l=e485413c15

Video:

http://shelby.tv/video/youtube/8hhXZwLFfao/facebook-stories-speeding-up-science

文章原稿:
Science. 2011 Apr 29;332(6029):537.
Life in science. Ichthyologists hooked on Facebook.
Sidlauskas B, Bernard C, Bloom D, Bronaugh W, Clementson M, Vari RP.

Ichthyologists Hooked on Facebook

The Cuyuni River, which runs from Venezuela through Guyana and into the Atlantic via the Essequibo River, harbors hundreds of fish species. Although much of the river flows far from civilization, pollution from gold mining and other environmental hazards threaten its rich community of wildlife. Earlier this year, a small group of us from the United States and Guyana set out to perform the first comprehensive survey of the river’s fishes with support from the Biological Diversity of the Guiana Shield program at the Smithsonian’s National Museum of Natural History. We aimed to determine which species still thrived in the river, which might have disappeared, and whether any of the remote river’s denizens were entirely new to science.
We arrived in January, during the dry season, and embarked for two weeks of collecting and camping along 200 km of rainforest-lined river.

Local boatmen helped us navigate the often perilous river, and each day, we stood neck-deep in the muddy waters and pulled wide nets to catch samples of the life teeming beneath the surface. One student, Whit Bronaugh, photographed each species as the collection grew to hundreds, and then thousands, of fishes large and small.

Upon returning to Georgetown (Guyana’s capital), a major challenge confronted us. As a condition to securing an export permit, we had just one week to complete a detailed report with each of our 5000 specimens identified to genus and species. Given the limited library resources at our disposal and the time constraint, the task seemed impossible.

Then one of the students, Devin Bloom, suggested posting our many photographs on Facebook and inviting the ichthyologists among our circle of friends to help us identify them. Would that far-flung community take the time to help us? We decided to find out.
We posted the photographs (1), and within minutes comments began to pour in. “They look like fish to me” one commenter cheerfully acknowledged. On an anchovy, another noted, “Pizza topping.” But before long, more insightful messages began to appear. On a catfish: “would say Megalechis personata,” followed by another suggestion, “my guess would be Megalechis horacatum.” Amazed, we collected identifications from our friends, and then from friends of friends, contributing their expertise from around the world. Less than 24 hours later, 90% of our specimens were identified. Armed with our export permit, we packed
our specimens for shipment and returned home, grateful beyond words for the generosity of our colleagues, and for the social network that allowed us to harness their vast collective expertise and provide faster and more accurate identifications than we ever would have dreamed possible.

首次台灣開放街圖研討會(SotM Taiwan 2012)的記事

開放街圖 (OpenStreetMap) 計畫已經在台灣進行多年,隨著開放街圖在全球知名度大開,台灣的製圖參與者 (mappers) 與日增多,台灣開放街圖雖然沒有政府部門開放資料與製圖相關的商業團體支持,在 mappers 一步一腳印地繪製,台灣地區資料量也日漸豐富,但相對於鄰近日本,以及歐美各國,台灣開放街圖仍然不足,亟需更多 mappers 的加入。台灣 OSM 社群目前缺乏系統性互動討論,以及更深入地對於技術發展、應用推動、和交流的平台,因此極有必要舉辦台灣 OSM 研討會,讓以社群為主的地圖成為各界共同討論的目標,達到概念性與技術性的交流。

此次報名人數超乎預的踴躍,截止前已超過100人,因為場地的限制,過多的人我們無法容納,但讓我感到揪感心的是報到率出奇之高,當天來了80位左右的朋友,做為首次舉辦的研討會,尤其OSM Taiwan的社群又相對於其它社群規模小,能有這樣的數量已經感到十分滿足,謝謝大家的支持!

當日議程和投影片都放在SotM Taiwan 2012活動網頁,本次研討會榮幸地邀請中研院資訊所副研究員莊庭瑞博士,就「大眾協作與個人記憶」為主題,講述群眾外包的地圖特性與合作協同過程中如同透過地圖編輯保存共同的地方記憶,當天上午並有6個演講,涉及層面廣,從Open Data、防災、歷史地圖、教育到授權,下午則是台灣 OSM Mappers較為實務性的分享。所有的演講都有錄影,並置於YouTube,感謝OSSF同仁錄影並整理上傳。

當天本人統計分析一下台灣Mappers的製圖特性,做為開場,投影片在SlideShare:

我們這種小地區的SotM,ito world並不會幫我們做過去一年的製圖概況,因此自已親手做了一個利用CartoDB+Torque的版本:

http://geocyber.org/maps/osm/sotm2012/taiwan_osm_2012.html

SotM Taiwan 2012的活動照片:
[fsg_gallery id="1"]

群眾外包的訊息平台 — Ushahidi

Ushahidi 是一套著名的群眾外包 (Crowdsouring) 平台,被運用在許多世界上重大的災難事件中,它的出現是因為2007年非洲肯亞總統大選出現爭議而暴動,為收集肯亞各地暴動資訊,Erik Hersman等人建立了一個以電子郵件和簡訊方式收集暴動事件之資訊,並顯示於Google Map 上,此平台並命名為 Ushahidi ,即為非洲斯瓦希里語 (Swahili) 的「證詞 (testimony)」或「證人 (witness) 」之意,而 Ushahidi 以收集群眾所提供的災難資訊,並繪製於地圖上的方式,也稱為災難地圖 (Crisis Map) 。
Ushahidi平台建立於 Kohana 網頁架構,也就是一個PHP 5 為基礎,提供許多豐富的套件以用來建立網頁, 為 CodeIgniter 架構 (PHP 5 開發環境) 的一個分支。在簡訊收集方面,Ushahidi並內建 Nexmo,用來處理大量手機簡訊(Shot Mobile Message)的API,以及 Clickatell 來提供收集簡訊閘口 (gateway),此外,Ushahidi 也常使用 FrontlineSMS 來收集使用者所發送的簡訊。在地圖顯示方面,Ushahidi使用OpemLayers套件為災難訊息地理視覺化的工具,使用者透過這個套件可以將災害訊息定位,所收集的災難訊息也可以分門別類地顯示於地圖上。圖1為我們所建立的測試平台。

圖1: 我們所建立的Ushahidi測試平台

圖1: 我們所建立的Ushahidi測試平台

SwiftRiver是擴充Ushahidi資料收集的系統,該系統結合自然語言處理和資訊探礦的處理套件,能分析使用者所上傳資料,如Twitter和簡訊,在短時間內,幫使用者分類並提供使用者充份的背景資訊,讓使用者更容易提供資訊,另一方面,資料收集者也因為充份對上傳的災害資訊分析,能有效地歸類整理災害資訊,而使所收集的資訊能加以利用,因此SwiftRiver被定位為具有所生產一個智慧且即時的資料收系統。SwiftRiver具有三個主要功能:1) 組織未結構化資料、 2) 條件式過濾和即時分辨上傳訊息的優先程度、 3) 加入有意義的脈給 (context) ,如位置,圖2為SwiftRiver的使用介面,對於來自於Twitter的事件報告,可以進行內容的過濾與辨識,以利後續分類及訊息分送。

圖2: SwiftRiver的使用介面

圖2: SwiftRiver的使用介面

Ushahidi在世界各地及重大災難事件的使用

(1) 2010年海地地震

在2010年海地地震發生沒多久,哈佛大學人道計畫(Harvard Humanitarian Initiative) 發起人之一, 利用Ushahidi 開啟了一個三個單位聯合的海地人道救援計畫,包含美國塔夫茲大學佛萊契爾法律外交學院(The Fletcher School of Law & Diplomacy at Tufts University)、哥倫比亞聯合國人道事務協調辦公室(UN OCHA/Colombia)和危機資訊製圖者國際網絡(the International Network of Crisis Mappers (CM*Net)),在該計畫開始後的幾個小時,即有許多的人道救援和技術的工作者加入,近40000筆的事件報告被傳送到這個海地地震的Ushahidi,之中有約4000筆的事件被標示於地圖中,圖3這個海地地震的Ushahidi。

圖3: 用來收集與報導2010年海地地震之相關災害訊息的Ushahidi

圖3: 用來收集與報導2010年海地地震之相關災害訊息的Ushahidi

(2) 2011年紐西蘭基督城地震
在2011年2月22日的紐西蘭基督城地震後24小時, 基督城復原地圖(Christchurch Recovery Map) 即利用 Ushahidi 建立起來,該網站標示了重要物資訊息,如食物、水、廁所、燃料、ATM和醫藥用品,其訊息由Twitter以#eqnz這個雜湊標籤、簡訊和電子封件來收集,這個網站由一群網站專業工程師和志工來建立與維護,如圖4所示。

圖4: 基督城復原地圖

圖4: 基督城復原地圖

(3) 2012年東日本大地震

2012年東日本大地震之後,Ushahidi被使用來交換傳遞地震災情與救援相關訊息。圖5為利用Ushahidi建立的日本復原地圖。

圖5: 日本復原地圖

圖5: 日本復原地圖

(4) 2011年美國密蘇里河洪水

MightyMoRiver 計畫是使用 Ushahidi 為 Crowdmap.com 服務的平台來追蹤2011年美國密蘇里河洪水的災害事件。

圖6: 密蘇里河洪水事件災害地圖

圖6: 密蘇里河洪水事件災害地圖

(5) 馬其頓共和國的貪腐事件報告

透明觀察計畫是使用 Ushahidi平台來追蹤馬其頓共和國的貪腐事件, PrijaviKorupcija是一個由馬其頓國際透明組織(Transparency International – Macedonia)和國際關係中心(Center for International Relations)聯合的計畫,旨在使公民可利用手機簡訊、電子郵件和twitter的雜湊標籤#korupcijaMK 來報導馬其頓貪腐事件。

圖7: 馬其頓共和國的貪腐事件地圖

圖7: 馬其頓共和國的貪腐事件地圖

各國在開放地理資料(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